This post summarizes the weekly editor chat meeting on Wednesday, 9 October 2019, 14:00 WEST held in Slack.
WordPress 5.3 is planned for next week, there are still some issues we need to fix before then:
Some of the priorities are being worked, but others are not taken yet. If you think you can help with some of these tasks, please leave a comment on the issue!
It is also essential to address some browser issues, namely on IE. People with a windows dev setup could be beneficial here.
We are getting close to the WordPress 5.3 release; testing is essential, namely on the mobile phone you use, given the wide variety of devices that exist.
Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!
- Working on the Media Upload errors handling.
- Working on a fix to the navigation mode.
- Lots of reviews and coordination.
- Exploring some improvements to Block 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. nesting selection with a new Block Breadcrumb.
- Continues the work on DimensionControl https://github.com/WordPress/gutenberg/pull/16791, and ResponsiveBlockControls https://github.com/WordPress/gutenberg/pull/16790 PRs.
- Started on the implementation of a potential new Link insert/edit interface as per https://github.com/WordPress/gutenberg/issues/17557
- Helped @epiqueras to land the initial version of the Components Storybook.
- Is focused on some optimizations related to eliminating dead code (mostly for experimental features) from WordPress 5.3 release.
- Worked on some changes to the custom gradient picker. Now, it is possible to move the control points using arrow keys, and the code was reorganized. It should be ready for a more in-depth review; a11y 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) feedback would also be valuable.
- Focused on some 5.3 must-haves.
- Helped (reviewed tested, or suggested commits) in navigation block (related PR’s), DimensionControl, ResponsiveBlockControl, and other smaller PR’s.
- Will continue the work on must-haves, apply a refactor that makes media&text work on IE, and fix some generic block editor issues.
- Hoping to revisit displaying a notice of some kind in the inserter when there are disabled blocks (https://github.com/WordPress/gutenberg/pull/17338).
- Help out with any 5.3 issues that he can.
- Will try to help get through some of the new issues, label them, and get additional attention to them if he thinks they are WordPress 5.3 must-haves.
@jeffreycarandang asked for an updated to PR https://github.com/WordPress/gutenberg/pull/17617 and to issue https://github.com/WordPress/gutenberg/issues/17809.
Regarding PR https://github.com/WordPress/gutenberg/pull/17617 @youknowriad and @jorgefilipecosta both had some comments on the problem the PR faces. The basic idea is that when a format is applied to a rich text, the focus goes back to the rich text (e.g., when we press a “bold button” it is expected I can continue typing) this behavior was always present. Some time ago, mainly because of accessibility 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) reasons, a change was applied to popovers that automatically closes them when the focus is outside. The two previous behaviors together have some impact on formats that are applied in a popover (the popover may close in an unexpected situation). This is a high priority very complex problem, and a solution is being worked.
@welcher asked more detailed feedback on https://github.com/WordPress/gutenberg/pull/16384 which adds a priority mechanism to the Slot&Fill pattern.
@mcsf and @youknowriad shared strong reservations.
It seems that priority and order are very visually focused, in stark contrast with how Gutenberg 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/ has tried to use SlotFill so far.
In Gutenberg, we talk about advanced settings, inspector, etc., instead of the visual element sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. Coming back to priority, what does it mean for SlotFill as far as selective rendering goes? how is a sequence determined semantically? etc.Why does this matter? Well, the bridging of different platforms and environments under Gutenberg is an important factor. If a codebase needs to work transparently across Web and Mobile, for example, its semantics needs to be clear and independent of a particular visual expression (e.g. Web on Desktop)@mcsf
@mkaz had a docs related question:
How do y’ll feel about ES5 support in documentation? Most of the code and package docs are ESNext, but we show ES5 examples first in docs. I don’t have a proposal together yet, but I feel we should move people quicker to ESNext since it is what they most likely will experience everywhere.
People agreed that the default docs should be ESNext but ES5 examples should still be present.