Editor chat summary: 31 July 2019

This post summarizes for the weekly editor chat meeting on Wednesday, 31st July 2019, 13:00 UTC held in Slack.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 6.2

This week, we celebrate the Gutenberg 6.2: a release packed with many improvements and bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, including: 

  • Button blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. target support, 
  • No limitations in nested blocks for Media, Text and Cover blocks,
  • New APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to register block style variations, 
  • Control the available RichText formats
  • And much more…

For a full write-up see this post: What’s new in Gutenberg? It’s great to see that we have contributors from all around the world. Thank you all! But as exciting as this release is, even more amazing things are in the works!

Last week we talked about the need for more reviewers to help out with the growing numbers of open PRs. The number of people who were actively helping in the reviews this week was noticeable. Big kudos everyone.

Task Coordination

  • @youknowriad and @gziolo expressed concern about the growing list of PRs.
  • @karmatosed is triaging PRs.
  • @nadir is looking for feedback on draft PR for implementing snap grid.
  • @kjellr looking at tips and adding a second-level help panel. Made improvements to the nested block borders, and a lot of cleanup for the Gutenberg Starter Theme.
  • @swissspidy Currently working on allowing non-consecutive multi-selection of blocks,
  • @mapk is looking at some design pivots on the Nav block, helped @danr with a few Table block improvements and looking at how block mover icons feel when they appear only when the block is selected. 
  • @brentswisher plans to work on some updates to the documentation to help clarify some things to other newbies like me. Probably continue with the draft PR exploring publishing flow updates.
  • @tellthemachines is close to wrapping up the experiments settings page and hope to move on to nav-related things.
  • @youknowriad  desperately working on landing the a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) navigation mode to hopefully land it for the next release. Started working on a “Help Panel” in the inserter to help users when picking blocks.
  • @gziolo working on unifying text blocks and features they offer:
    • refactoring those blocks to use has-text-align-* classes internally to make styling easier
    • Alignments now collapsed and can be applied through dropdown menu
    • Working on improving our warnings displayed on the Web Console for developers who develop for the block editor:
  • @andraganescu working on extra bits connected to the navigation menu block and the media flow component to remove the icon button.
  •  @noisysocks shared that is working on Inline Tips.
  • Key feature development to allow non-consecutive multi-selection of blocks by @swissspidy

Open Floor

  • @tellthemachines commented on ways to communicate the updates from people in the APAC region. “We’re trying out posting updates as comments to the meeting agenda. It would be nice to give this some visibility so more folks from different timezones feel encouraged to participate. Also, let us know if you think this method is useful and/or if you have any other ideas on how we can improve communciations!”
  • @nadir had some questions about how can I handle search & external libraries. He is working on an Icon component that should have a list of icons to select from, and looking for suggestions.
  • @youknowriad responded to @nadir:
    • For the search component: we might want to take a look at how the “link format” is built in order to share components/consolidate?
    • – The icons list is another good question we need to figure out. An initial approach could be to pick from the list of the Dashicons SVGs (they’re available in the Dashicon component)
  • @matias Suggested that some of the block libraries out there have good ideas for icon selection and filtering.
  • @nicolad is working on and has some questions about Social links block.
  • Responding to @nicolad, @youknowriad believes that we might want to share the same mechanism of providing icons between the Social Links block and the Icon block maybe? The question is how to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. that list for social icons only, or even do we want to filter it?
  • @brentswisher:  last week when asking about the process of reviews, I was given the advice to review and if all was good to merge the change. Then when reviewing the documentation, I found this which conflicted with the documentation: The final pull request merge decision is made by the wordpress/gutenberg-coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team.
  • @youknowriad suggested the process should be:
    • *I review it
    • *If it looks good to me approve, and mention someone on the core team saying it is ready to merge.
    • *If someone from core says it looks good to them merge it
    • *If nobody comments in a day or two go ahead and merge it anyways.
    • I’m hoping to update the documentation to make this process more transparent and just wanted to verify there was some consensus about that process / get opinions here first. 
  • @brentswisher will work on writing an update to the documentation,

Note: Anyone reading this summary outside of the meeting, please drop a comment if you can/want to help with something.

The agenda for the next meeting, 7 August 2019 13:00 UTC is here, please add anything you want to discuss.#meeting-notes, #core-editor, #editor, #gutenberg