20 Comments

  1. Rich Tabor
    · Reply

    The front end of a site is the theme author’s domain. Ultimately, they define how things work there.

    I tend to lean towards the thought that the front end of a site is the user’s domain. They ultimately decide what’s what.

    In this new paradigm of Gutenberg and block themes, the theme builds upon the base provided by core, which can then be modified by the user (eventually through Global Styles).

    Report

    • Rodrigo
      · Reply

      How can the front end be the user’s domain if core starts to decide which is the “right” way to create web layouts, with no possibility of change? ​

      To me, what this kind of decision seems to imply is that, in reality, the front end is now core’s domain and that anybody can be — or want to be — a theme designer, because all those boring details can be decided beforehand for them, with complete confidence and effectiveness.

      If that’s the case, this actually devalues a lot of the figure of the professional theme designer as we know it and will (possibly) remove a lot of nuance from this activity.

      Report

    • Cano Ode
      · Reply

      Good. So, no more themes?

      Report

  2. Ellen
    · Reply

    Hi Justin,

    Thanks so much for highlighting the discussion that started with the introduction of the global gap setting. To be honest, I’m still not sure what to think about it.

    From my perspective currently, yes a responsive global vertical margin setting can be a good idea for some default blocks, but I can think of so many cases that I don’t want to have this in my designs.

    In my opinion the block Editor brings the possibilities for more advanced individual designs to WordPress, so I see an issue with introductions of very generic settings that might become mandatory to use. That just does not sound great to me.

    I think themers, pattern designers as well as users should have the possibility to adjust any setting, but it should be the design creators choice to opt-in or out of a particular feature in their project.

    At least this is how I hope it will be, since as you said it should be possible to build anything we want with WordPress.

    Report

  3. Ellen Bauer
    · Reply

    One thing to add is that I really think the idea of custom spacing values (as Rich describes here: https://richtabor.com/standardizing-theme-json-spacing/) in theme.json that can be applied flexible to a design system is super smart and helpful in my opinion.

    I think that somehow I still misunderstand the spacing setting in theme.json a bit, since I see the advantage of custom settings for sure, but I have difficulties with general settings applied (which will be opt-out now, as I understand).

    Maybe there should be a more detailed documentation on the settings in the Editor handbook?

    Report

  4. Jeff Safire
    · Reply

    Are we approaching a time when the “Default Theme” is the only one available for WordPress?

    Themes are built by (mostly) creative people. They offer the user a choice in how they want their website pages and posts to look. Why then would we want to limit what that user can do because a software default two levels up is take it or leave it? Do painting artists have a restriction on how many elements they are allowed on their canvass?

    Having too many unchangeable default settings simply stifles the creativity of the theme developer, and thus, the user. And limiting that creativity may one day cause many websites to have the same “look” – much more than some do today.
    –––

    Report

  5. Andre
    · Reply

    Quoting “I guarantee that someone will come along and use CSS grid.” is ironically related to a multi-tweet I did earlier today about the redesigning of my site and that I am getting fed up with flexbox for “columns”, media & text, etc. I discovered breakpoint issues in the core block styling…long story short, I had to override the flex for CSS Grid to give me more control.

    I would have posted a link to that tweet, as it does have a screenshot to show the issue(s), but wasn’t sure if I can do that here.

    Report

  6. Patrick B
    · Reply

    When I am designing a theme for a client I surely hope I am doing more than just bringing “personality and design”, and I sure do spend a lot of time considering the vertical and horizontal alignment within the design. Spacing is fundamental to design.

    I remain excited by the block editor, it’s the reason I stick close to core because I could invasion a theme experience I want to bring to clients that I couldn’t find with meta-fields or page builders. But I do worry that the experience will end up begin one of fighting the system and creating workarounds.

    Each time a new setting is introduced I also tend to think of the decisions, not options moto. It’s been my fear that we end up building out a system that’s a page builder equivalent ( I think there is plenty of space for that and plugin developers have shown they are the ones to do it for those who want it). I think having a base provided by core is a fine idea, but I also think it’s a good idea to be able to remove optional block settings as theme authors see fit. Part of the idea of theme.json that excited me was the potential for more granular control over those options. I run into this with the new margin and padding settings. While I would like a way to present theme users with some options to control spacing that fit within the pattern of the design ( block styles just aren’t up to the task ), I don’t want to present clients with manual spacing controls ).

    Report

  7. Daniel
    · Reply

    As mentioned in the ticket, the inspiration for this “gap” comes via https://every-layout.dev/layouts/stack/, an iteration on the earlier Lobotomized Owl selector * + *. This approach is a super direction to go and my hope is Gutenberg’s CSS will start reflecting more of this type of thinking! Some nuance is definitely needed to allow for alternate gap values; the current implementation is a bit robotic by presuming all block types to benefit from the same gap value.

    The power of this approach will be diminished unless blocks are allowed to remain “dumb”. Dumb blocks work in harmony within the “stack” layout: a dumb block doesn’t need to know or understand anything about its place in the world, and it should never need to. No matter if there’s 1, 5, or 10 blocks on the page, in any configuration the layout can be automatic and predictable when managed with CSS that targets the context and not the individual block.

    In contrast, every time I see a request for “responsive controls” at the block level, I cringe. Baking in a margin value can make a block a little smarter by optimising it for a specific location and screen size. Rearrange a few of these blocks and a broken layout can easily be the result, requiring each block to have its personal margin be re-optimised.

    Very interested to see how this develops.

    Report

    • Matías
      · Reply

      Exactly, you hit the core of the problem and approach. Since we are just rolling out the initial container settings for blocks it will look a little rough until more nuance is added. There will always be escape hatches for more specific control, but we it should be deliberate.

      Report

  8. Stephen Vaughan
    · Reply

    I’m going to rob your idea Justin. I am starting work on the stumbling block…

    Report

  9. Mike Schinkel
    · Reply
  10. Robert Lilly
    · Reply

    To me, this statement from the blog post sums things up perfectly: “Build a system that they want to use, not that they must use. And, for those who decide to go a different route, make it easy. Even if we think those rebel designers are creating a broken user experience, that is OK. It is their project to make or break.”

    Report

  11. Sally G.
    · Reply

    I just came to quote what Mr. Lilly just did, though I selected a smaller version: “Build a system that they want to use, not that they must use. ”

    Applies to WordPress, certainly, but so much more as well! Important attitude in so many areas of life.

    Report

  12. Matías
    · Reply

    I think a few cables got crossed in the conversation of the ticket! Ultimately, the idea for these container settings is that they absorb a lot of the concerns for laying out blocks, in turn removing a lot of the structural complexity from themes, but they should not remove control. The whole point, in a sense, is to provide more control but in a way that scales better and integrates better — block spacing is something that can act on all blocks, for example, even if you don’t know what blocks are present.

    In the current state it’s not refined enough to allow variations in vertical rhythm (headings are generally a good example) so it should remain opt-in. We might need to introduce a way for declaring different levels of baseline rhythm that blocks can declare and themes can control globally. Once this setup is final the hope is that themes won’t need to opt-in or out but merely configure a default and build upon it as needed. Of course, escape hatches will be necessary since absolute flexibility would be a requirement for multiple sites and setups. Once all is said and done we’ll need to show various examples of how a “normal” theme might be setup compared to a fully locked down one.

    A question of defaults is still relevant, though it might be more for themes showcased in the theme directory, in the sense that drastically different functionalities for users can be confusing when they switch themes and lose access to them, but I digress a bit there.

    For the next few weeks we’ll be establishing the major parts of design tools and global styles. Soon after a proper review needs to be conducted, including tweaking the defaults across all blocks (for example, what typography tools make the most sense to be present by default in a paragraph vs a heading). The iterative nature will mean a few things might need to start opt-in and move towards opt-out once things settle a bit more.

    Report

    • Justin Tadlock
      · Reply

      Of course, escape hatches will be necessary since absolute flexibility would be a requirement for multiple sites and setups.

      I think that solves everything most developers are concerned about.

      Report

  13. arshit
    · Reply

    Each time a new setting is introduced I also tend to think of the decisions, not options moto. It’s been my fear that we end up building out a system that’s a page builder equivalent ( I think there is plenty of space for that and plugin developers have shown they are the ones to do it for those who want it). I think having a base provided by core is a fine idea, but I also think it’s a good idea to be able to remove optional block settings as theme authors see fit. Part of the idea of theme.json that excited me was the potential for more granular control over those options. I run into this with the new margin and padding settings. While I would like a way to present theme users with some options to control spacing that fit within the pattern of the design

    Report

  14. Matt
    · Reply

    I might be misunderstanding the issue, but can’t you already split the built core block styles and then dequeue them individually?

    Using something like: wp_deregister_style( 'wp-block-gallery' );

    Then enqueueing your own styles?

    Report

    • Justin Tadlock
      · Reply

      We’re not specifically talking about a block stylesheet. But, that is actually a good example where core has made it easier to opt out of something, which is very much a good thing. I would like to see that level of granularity with any design-related feature.

      The primary example in this post outputs inline styles for all blocks. It’s a global top margin, and there was no way to remove it. This would force themers into a specificity battle and bloat CSS. Fortunately, they have actually made it an opt-in feature with the goal of eventually turning it on by default but allowing theme authors to opt out.

      But, the crux of the issue is that it was intentionally made to not be overwritable from the outset.

      Report

  15. Enno
    · Reply

    From a designer point of view (and by that I mean someone who understands and can handle CSS — not the type of ‘designer’ for example the Elementor marketing team seems to have in mind) I welcome every way and opportunity to disable Gutenberg/Block Editor features that offer design options, be they automatic (like that new gap thingy which is at the core of this thread) or offered by interface, like color options and such in the block options panel. I am very glad that in my themes I can at least by now control the color options (as an example) through the theme JSON file, and I am maybe just to blind to have yet found an option to entirely get rid of it, or any design related interface in the editor (I hope there will be an easy way, eventually). I love Gutenberg aka the Block editor, but I love it for the gift of easily building structure. I prefer to literally entirely control the layout through the style.css. Of course there are tricks, like dequeueing the core style sheets, but it would be so beautiful if there was a universal opt out option for anything design that is delivered through block editore core functions. As for the top margin, to be more on point: it is something, I never ever would do to get spacing above an element. I would always add padding to the element or a wrapper. So, regardless whether that is good or bad practice (I don’t believe, btw., anyone could convince me that it is a bad practice), I should be given the possibility to keep using that approach in designing my themes. Denying designers an opt out seems to me almost an arrogant approach from sides of the WP/Gutenberg dev team. Just my five cents, no offence …

    Report

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.

%d bloggers like this: