This post summarizes the weekly editor chat meeting agenda here. Held on Wednesday, 30th October 2019 held in Slack, moderated by @mcsf, notetaker: @pbarthmaier.
Weekly Priorities
Gutenberg 6.8 and WordPress 5.3RC3
Gutenberg 6.8 had its RC on Monday and is ready to be released. @ella has offered to wrangle the release and release post! (edited)
The third release candidate for WordPress 5.3 is now available! WordPress 5.3 is currently scheduled to be released on November 12 2019, but we need your help to get there—if you haven’t yet tried 5.3, now is the time!
A few things that might be good to fix in time for a potential WP 5.3 RC4:
I’d appreciate some eyes on these! I believe @jorgefilipecosta had something prepared for the latter.
November Gutenberg Priorities
Priorities for the coming month are categorized into these three headings:
- Block Content Areas,
- Menu Navigation Block, and
- Tightening up existing interactions
For more details, consult this recent post.
Task Coordination
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
@getdave
Related to Nav Menus – a new experimental Link UI to standardise the interface for adding links has been merged.
Also merged experimental `DimensionControl` to provide a standardized user interface for controlling Block dimensions.
This is closely linked to the ongoing PR for `ResponsiveBlockControl` which enables per device/viewport settings for a given control https://github.com/WordPress/gutenberg/pull/16790. These are both related to the wider goal of enabling padding/margin adjustment on the Group Block via the editor. Looking for input and feedback on the later PR.
@joen addresses a frustration with the complex left and right margins and paddings that every block gets in this PR: this should make things easier for block developers and themers, ie styling the editor and building delightful blocks without complex CSS. The downside is, it’s a complicated refactor, and it will create issues in some existing editor styles, like TwentyNineteen. But I would argue it’s worth it, and a perfect candidate for kicking off the 5.4 cycle once 5.3 lands.
@mcsf I’ve been targeting a good deal of my reviewing to the monthly priorities. Folks have worked a lot on improving the block appender and other pieces crucial for the Menu Navigation block, kudos to them
@andraganescu I am working on adding a link to the media and text block, fixing the selection when switching inspector tabs and reviewing/testing everything open for the navigation menu block
@gziolo I’m slowly learning about Patterns API for block and I plan to start development later this week. I also spent a lot time reviewing new stories for the Storybook and further polishing the integration with snapshot testing
@jorgefilipecosta Since the last week, we iterated and merged many of the gradient related PR’s. We now use the class mechanism on the button gradients. I helped the new experimental colors hook to land, and I have been involved in refactoring some blocks to be functional components so we can use hooks there. For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block.
@brentswisher Following up on old/stalled PRs – If I could get some new eyes on https://github.com/WordPress/gutenberg/pull/11070 specifically it would be great to wrap up, it’s been going about a year…Continuing to work on Storybook and file some related
@gziolo and @getdave give props to @itsjonq @mkaz @brentswisher and @enej for working on adding stories to Storybook too which makes testing a pleasure and helps us uncover all incompatibilities that folks can have when integrating components into their own project.
@retrofox Working now integrating https://github.com/WordPress/gutenberg/pull/18062 and https://github.com/WordPress/gutenberg/pull/18172 – apply colors correctly in editor mode
@jorgefilipecosta For the next week, I will focus on some enhancements to inner blocks that allow removing parts of the standard block UI. And try to apply these features in the buttons block. and improvements to the standard block UI can ultimately also improve the experience with Nav Menus
@mkaz Over the next week I hope to work with Joen to iterate on SVG loading. Hopefully one step for unsticking the Social Links.
@mcsf Relaying async updates from our APAC friends:
- @tellthemachines: “I’ve been working on and reviewing nav menu issues. Current PR for showing appender only when item has submenu
-
@noisysocks: I’m focused on reviews this week: particularly Nav block PRs and this Widgets PR.
Open Floor
@marek asked if the screenshot on the Editor Component page needs updating https://make.wordpress.org/core/components/editor/ @mcsf proposed anyone with a more current screenshot to add it to a future Agenda post in the comments and anyone on the team with write-access to the component page can edit it
Specific Area Blocks
@aristath asked if the plan is to have blocks specific for these areas (like for example a branding block for the header block-area)? If so then these blocks will only be usable is the block areas for which we register them and won’t be available in the content?
@jorgefilipecosta replied this could fit into the concept of child block where a block specifies it only makes sense inside a specific parent. It may be possible to use the current API’s and specify a branding block needs to be child of a header block, but that you may need to also use a branding block in the footer.
@mcsf I suggests this may work with block categories so that certain categories (“Page Layout Elements”?) aren’t meant to show up in post content.
@aristath from the theme team asks if there is code for review so the team can begin thinking about what needs to be done for themes (how they can override templates for registered blocks, what/how can be registered etc)
@poena I am seeing a lot of different screenshots in various github issues but is there actual example code for us to test?
@mcsf Are you asking more about block insertion and management UI, or about the front-end / template rendering aspects? There’s a few issues on different aspects
@aristath I’m asking about the template-rendering aspects, how they can be overridden (not all themes have the same branding components), if themes can register blocks for block-area A/B, if there’s anything we can start looking at. The UI doesn’t really matter, what we need at this point is to get an idea of what a theme can/should do code-wise to implement a feature. Even if it’s just a rough draft or an idea of where we’re headed .
@mcsf I think this a good starting point. A lot of issues and PRs, some of which merged, point to it, so be sure to scroll down to find some of the merged work around wp_template too. From the standpoint of overall user experience, this issue is a good aggregator.
@vindl Currently we already have a concept of child block. Where a block specifies it only makes sense inside a specific parent. FSE-related (Full Site Editing) – would it make sense to extend this beyond blocks and make it possible to declare parent post type limitations (e.g. template-part block can only be inserted in wp_template CPT or similar)
@marek It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Not sure how much this was explored so far.
@williampatton It might be interesting to see those Site blocks being styled based on the area they are in. In the header, Site Title would be big and prominent while in the footer it might be more subtle by default. Is the idea that the editor would be responsible for styling this?
@mcsf I personally see this is going beyond styling. Rather, we should have an editor (and blocks!) smart enough about block semantics that they a block can mean (and behave?) differently depending on where it’s inserted.
@marek I would think the editor provides classnames for areas and blocks and themes will handle those.
@williampatton I would prefer this aspect to be agnostic of the editor it. Ideally the editor doesn’t know/care where the items were and the frontend could handle all styling.
@poena This gives us an overview, how do we practically (and realistically) help move this forward?
@mcsf This gives us an overview, how do we practically (and realistically) help move this forward? Maybe some of those most involved in recent full-site editing efforts can weigh in? If not, this can be something to follow up via P2 comments — would that be acceptable, @poena? I’d say that the November post would also be a strategic place to follow along and align.
@poena I don’t know how you normally introduce new contributors
@mcsf that’s a great question. And, by the way, welcome and thanks for wanting to help! My personal impression is that full-site editing has been moving through different pieces that can be explored separately, which is good for velocity and collaboration, but also makes it much harder to jump in and get an immediate lay of the land. There doesn’t seem to be a single branch we can check out and start working on. it’s bits and pieces scattered all over the place. I’m sorry there was no super conclusive answer, @poena and @aristath but hopefully this is a starting point.
Thanks everyone for joining and for all the work!
