Javascript Chat Summary – October 8, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Open Floor

There was no agenda items this week so the meeting was spent with open floor.

Storybook Chat

Spent a bit of time chatting about efforts to get storybook working (slack)

Related pulls:


WordPress 5.3 Notes

  • will include an updated version of Backbone that introduces some back-compat breaking changes (related trac ticket). If you use backbone in your plugin/theme, worth checking to make sure everything still works. A dev note will be published soon including details.
#javascript, #meeting-notes

Javascript Chat Summary: October 1, 2019

Below is a of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

WordPress 5.3 progress

@gziolo announced that WordPress 5.3 release beta 2 is out. @gziolo asked if participants know if there any tasks left related to JavaScript core.

@jorgefilipecosta referred as a small JS patch that should fix a bug in the media library. The patch should be ready and needs a review. A review there would be much appreciated.

@gziolo continued by saying it would be important to merge, which would simplify updating npm packages in WP core. But there is still this pending issue to address:

Where to put generated asset files to be consumed by PHP? At the moment they are generated in the folder, which in usual is exposed as client-side assets.

In case you have any ideas, please provide your insights on the ticket.

CSS support in wordpress/scripts

@gziolo introduced the subject by saying that it is something that we discussed some time ago in core-js chat. It’s tracked under, and it was primarily explored by @fabiankaegy in

Participants started discussing the challenge of CSS support in wordpress/scripts.

@gziolo shared some context:

In Gutenberg we don’t import CSS in JS files. Instead, we have a separate build step that converts the SCSS files into CSS files which are published to npm. There is some additional step performed by webpack, but I guess it’s mostly about ensuring the LTR version is produced as well.

@nerrad said:

I do think we should have @wordpress/scripts as a utility that builds CSS as well. But getting to something that addresses the various needs of those consuming it is the difficulty here.

@nerrad concluded that we need to decide the defaults for the CSS build system with ways to override them via CLI args.

@gziolo continued and said that ideally, we should be able to reuse as much as possible of what Gutenberg uses internally. This is the only way to ensure plugin/theme developers get all updates out of the box.

@gziolo questioned why developers default to importing CSS in JS file. @jsnajdr provided an answer to the question and then explained how the webpack runtime loads the assets. @gziolo found the mechanism interesting and said we should definitely explore alternatives in how we manage assets in WordPress core to better align with what JavaScript ecosystem offers these days. 

@gziolo continued the conversation and said that the mobile team is exploring how to build cross-platform UI components.

This is the PR which explores styled-system and styled-components.

@pinarol said we want to reach a point where we can build blocks with a cross-platform components library which enables us to implement a block once and run it on both web/mobile.

This requires the mobile team to find a way to have a common styling system with the web, and since CSS is not supported by React Native we started to investigate styled-system and styled-components. @pinarol concluded by saying that this is a problem we want to solve as soon as possible.

@gziolo said that the approach used for multiplatform comments is directly related to work of making wordpress/scripts support CSS.


@gziolo announced that we are considering adding Storybook to help with the development of UI components.

It is possible to leave feedback on the PR’s that propose this addition and They are alternative versions for a similar goal.

@ajitbohra also implemented a similar solution outside of the Gutenberg repository and said he would love to consolidate efforts.

Custom element interoperability

@flixos90 proposed a PR that includes CustomElement interoperability for block types

If you care about the support for web components in Gutenberg, give the PR a spin and help to land it.

In case, you have any insights or suggestions please share them on the PR.

#core-js, #javascript, #meeting-notes

JavaScript chat summary, September 24th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on this week’s agenda.

New JavaScript APIs and support for previous versions of WordPress

Discussion: @adamsilverstein suggested that we add a developer guide section to explain how to write plugins that use newly introduced JavaScript APIs to work with older versions of WordPress. The biggest challenge is how to approach APIs which are exposed by new modules available under the wp global namespace.

We encourage plugin developers to share their strategies in the comments so we could work on the official recommendations on how to tackle this issue.

We also agreed that a good start would be to enforce using the @since pragma in JSDoc comments for all public APIs present in JavaScript code. This is something that is taken for granted in PHP codebase.

Action items:

#core-js, #javascript, #meeting-notes

Editor chat summary: 18 September 2019

This post summarizes the weekly editor chat meeting on Wednesday, 18 September 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Many folks were in transit, which made this a less busy meeting than usual.

Gutenberg 6.5 Release

Releasing shortly. You can see the RC here.

This will be the last release that goes completely into WordPress 5.3.

This is released now!

Weekly Priorities

Help test the RC!

Now released and in trunk — Please help test!

Task Coordination

  • @nadir is working with @joen on improvements to the Separator block (may end up as new Divider block), and looking into making the Stylelint config more strict.

Open Floor

@paaljoachim wanted to bring attention to a couple tickets:

@mikeschroder brought up, which is in regards to adding height and width attributes back to images in Gutenberg.

This ticket had conversation that started on Twitter with a tweet from Jen Simmons. There is a WICG recommendation that Mozilla is testing (and sounds like Chrome is planning as well) that makes rendering faster if height and width attributes are provided for images.

@desaiuditd is looking for feedback on, specifically regarding details on how the proposed useFilter would work.

Note: If you’re reading this summary outside of the meeting, please leave a comment if you can/want to help with something.

The next meeting is on 25 August 2019 at 13:00 UTC.

#core-editor, #core-restapi, #editor, #gutenberg, #meeting-notes

JavaScript chat summary, Sept. 10th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @cbravobernal for putting these notes together.

Agenda: Upgrading jQuery when user on the front end.

@adamsilverstein comment the idea of upgrading jQuery on the front end, due to the crashes that appear if you try to update the wp-admin part. There was discussion about removing jQuery from all WP, but is a hard task to do and we have still to be compatible with old browsers like IE11.


Anything new should either not use jQuery or at the very least work with the current version correctly.

Keep the discussion going in the ticket and hopefully we can arrive at a way forward.

Out of agenda: jQuery dependency on admin bar

@williampatton raised this Issue regarding the jQuery dependency of the admin bar.

The main discussion is what to do, use a temporary patch (for 2020 theme we are considering just enqueueing jQuery) or try to completely remove the jQuery dependency of that admin bar.

Seems that a “hoverintent” is the main problem of removing jQuery there, also other keyboard actions should be checked before removing it.


Keep tracking the issue

#core-js, #javascript, #meeting-notes

Core themes chat summary for September 4, 2019

These are the notes for the weekly Twenty Twenty meeting which takes place on Mondays. You can read the full transcript on the core-themes Slack channel (archive link) and find the meeting’s agenda here (also on Slack, for this first one).


Thanks all around

The Twenty Twenty GitHub repo was made public on Friday, and there’s been a flurry of activity over the weekend with numerous issues posted and Pull Requests created. We’ll be working through them and will try to address all of them in time.


It’s a tight deadline, with just two weeks left until Beta 1, so major topics other than those alredy in the agenda were encouraged to be kept to GitHub.

Discussion Topics


Non-latin font fallbacks

A ”Support for non-latin font fallbacks” issue (#118) has been created, with calls for suggestions on which font fallbacks to include for each alphabet. There are lots of alphabets yet to be added, so suggestions are welcome. The issue could also use suggestions on how to best include the CSS for the different alphabets. @nielslange offered to take a closer look at that.

Whether to bundle a font

One proposed solution was to limit the font-family setting to serif and sans-serif. That led to a bigger discussion about whether a bundled font should be used, or if we should rely on a stack of system fonts like Twenty Nineteen. The arguments for using system fonts were that it reduces the size of the theme, and the page size of sites using it. The argument against is the user experience being uneven depending on which system the visitor uses. The discussion will be continued on GitHub.

Build Tools

Due to the tight deadline, the team has decided not to go overboard with using build tools for the theme.


The structure of the header menu locations was brought up by @joyously. Currently, the theme is intended to use three menu locations for the header. One for mobile, and two for desktop: a horizontal, traditional one, and one hidden behind a toggle. The arguments against the structure is that it could be confusing to the user, for two reasons:

  • The distinction between the two different desktop menus would not be clear
  • Users might not set a menu to the mobile menu location, and not understand why a menu is not displayed on mobile

A suggestion was made that the mobile menu can fall back to either the horizontal menu or the modal menu, if the mobile menu has not been set. The discussion will continue in a GitHub issue (#164).

Migration from jQuery to Vanilla JS

@fabiankaegy has created a PR for converting the currently jQuery based construct.js file to a Vanilla JavaScript one, using @wordpress/scripts. The discussion around it centered on whether @wordpress/scripts was needed. It was argued that including it adds a barrier of entry to new contributors, and that given the small amount of JavaScript needed to replicate the current jQuery functionality, @wordpress/scripts wasn’t needed. @fabiankaegy has since added a new PR without the build tooling, which can be found here: #163.

@audrasjb also raised concerns about removing the jQuery from the theme entirely, as the admin bar doesn’t function correctly when jQuery is not enqueued by the theme. This is described more in detail in an issue for Twenty Nineteen. @williampatton will try to look at the issue in Core and check if a fix is doable by 5.3. If a fix is not included in 5.3, it was decided that Twenty Twenty will enqueue jQuery when the admin bar is displayed, same as Twenty Nineteen.

Open floor

Due to the meeting already running 30 minutes long at this point, the open floor was skipped.


JavaScript chat summary, August 27th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on this week’s agenda.

Agenda: Cross-platform packages

Slack Conversation

In the near future we want to publish a mobile components library to allow cross-platform development of blocks, how can we document mobile/web specific props? The proposal currently only touches README files which are manually crafted. So far we assumed that this code is only used in WordPress. How could we make packages that are interoperable with both React DOM and React Native?

The mobile team is trying to make the API’s / Prop interfaces for mobile and webcomponents as similar as possible. But it will be hard to make them entirely the same. So we need to make sure we find a way to manage the documentation for these things better. Jorge Bernal will work on a proposal based on

#core-js, #corejs, #javascript, #meeting-notes

JavaScript Chat Summary: Aug. 20th, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @c4rl0sbr4v0 for taking these notes.

Our agenda was empty this week so all discussion arose from the open floor.

Introducing a new icon package

@nadir says that they will clean the PR of files auto-generated files and also that they were looking at a way to treeshake without the need to import individual icons manually.

There has been a discussion about including all icons in a wp.icons variable

  • Advantages:
    • Plugin developers that don’t use any build system have the ability to access our icons in their code.
  • Disadvantages:
    • We can’t load +1000 icon in a single script.

Possible solutions:

  • Select, download and manually include your icons in a web/cli tool like lodash or Material design.

This is a tough issue exploring the requirement for devs to include or not a build system and if this is overkill just to include a few icons.


Keep the discussion going in the ticket and hopefully we can arrive at a way forward.

Source maps in firefox

@pierlo asks for help with this issue:

Unable to load source maps from webpack in Firefox

@swissspidy asked if this is also a Gutenberg issue, referring a solution here


No actions debated in Slack channel.

#core-js, #javascript, #meeting-notes

Editor chat summary: 14 August 2019

This post summarizes for the weekly editor chat meeting on Wednesday, August 14, 2019 at 1300 UTC held in Slack.

The agenda can be found here.

Gutenberg 6.3 

  • @riad noted that this release is a very important release in terms of Accessibility because it introduces the Navigation Mode

Priorities for next week

Please don’t hesitate to help there. Provide a11y and design feedback. Help with tests… Let’s move these forward.

Task Coordination

Based on the links in Task Coordination, Riad extracted a list of PRs where feedback is needed:

Open Floor

There was a discussion about new core blocks being developed. The central idea is that some ideas, while good, are low priority, for example the gists block or the multi select dropdown.

Riad explained that the ideas for the blocks themselves are good but “we added components as we needed them in Core and Core blocks. Doesn’t mean we can’t add components for third-party authors if they prove to be useful for a lot of persons but we’d need contributors to champion these”

There is also a list of new blocks that are high priority and considered “blessed tasks” and the list includes: icons, menu, social icons, divider and other Full site editing related blocks (site title, post title, post categories).

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, 21 August 2019 13:00 UTC is here, please add anything you want to discuss.

#core-editor, #core-restapi, #editor, #gutenberg, #meeting-notes

Javascript Chat Summary: August 13, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda: Shared Core Dependencies


The Google Doc Agenda has much of the content of what was discussed, but as a summary:

Package/Bundle size for assets is a significant concern for frontend use as WordPress continues to expand javascript as a first class citizen in its ecosystem. Some examples where this surfaces are:

  • using wp.element on the frontend. It has a dependency on lodash which adds weight to page load.
  • implementing various components or blocks on the frontend (wp.components itself has significant size).

Some potential ways to resolve/improve this for not only frontend but also admin are:

Load externals via CDN.

Externals such as react, react-dom, lodash etc could still be registered but the source would be from CDN. The advantage here is with WP’s wide reach, it’s much more likely that client browsers will have cached the asset for visitors to WP sites. Currently that’s less likely because of every site hosting it’s own assets by default.

Action: @adamsilverstein is going to raise this in the hosting meeting to get feedback from there.

Size of packages.

Here, the focus is on how big are we willing to allow various bundles to get? For instance wp.components is 553kB minified.

  • should we start thinking about setting some comfortable limits on how big we allow bundles to get? (tools like bundlesize could help with that)
  • what ways can bundles be further reduced in size (example of @wordpress/server-side-render being extracted into it’s own package) – audit packages and see what other extractions/groupings can be done?
  • WP core supports script-aliases (enqueuing wp-components could actually enqueue X different files behind the scenes, all populating the wp global).
  • Reduce external dependencies: Example is lodash dependency removal from @wordpress/element. Much of the functionality of lodash can be implemented via native js.


  • It’d be good if those interested in javascript in WordPress start thinking through some of what’s been discussed in this item and contribute some proposals on how to improve things.
  • On the last item, removing lodash dependency from WordPress packages has been proposed. It’d be nice to get a decision on moving forward there. Please contribute your thoughts to the issue!

Agenda: Lazy Loading of Images and Frames

Slack | Trac | lazysizes library | Native lazy-loading for the web article

The discussion here centered around whether lazy loading of images is something that should be implemented in WordPress core and some initial ideas on what would be involved in doing that. Some highlights of the discussion (though no concrete decision was made):

  • opt-in for now
  • possibly implemented via add-theme-support
  • include for wp-admin as well (eg. Media Library)


  • continue to contribute to the trac ticket. Possibly explore landing something for wp-admin first.

Open Floor

  • @joyously asked about the status/possibility of updating jQuery (see trac ticket (slack convo). Nothing concrete from the discussion. Current blockers are the difficulty in resolving issues with the update and conflicts/failures with the customizer and media. Also reluctance exists to invest effort in something that may become obsolete due to changes in framework used (moving to more react heavy admin). Joy did note that the biggest problem existing right now are the flags raised by security scanners detecting the version number (author note: vulnerabilities in jQuery bundled with core are patched, but security scanners still detect it as a vulnerable version).

#javascript, #meeting-notes