- XD 14, December: Addition of node metadata, pan and zoom, and shared links APIs
- XD 15, January: Addition of assets panel APIs, and deep links for plugin listings
- XD 16, February: Addition of
- XD 17, March: Loosening of the edit context rules
- XD 18, April: Addition of more HTML text field controls, support for inline
styleattributes, support for sending
And the momentum continues!
This summer is going to bring some big updates to the API that will give you an expanded API feature set and a new option for insertion points, while enhancing the developer experience at the API level.
Below we’ll have a look at two important areas of the forthcoming updates. Then I’ll invite you to the XD plugin developer prerelease (tl;dr: email us to request access at firstname.lastname@example.org). In the prerelease, you’ll be able to try the alphas and betas in advance of the API updates coming this summer.
Web standards: bring your skills with you
XMLHttpRequest in XD generally behave as you would expect them to in a major browser.
The benefit of this approach is that, while XD plugin APIs do not operate in a browser context, you should be able to feel quite comfortable in the plugin API environment with your web development skills as a starting point.
This has been the vision from the start, and when the next major version of UXP is integrated into XD this summer, you’ll notice an even closer alignment with HTML and CSS web standards.
As a result, we’ll all get to enjoy these changes and more:
- Important: Improved font rendering
- CSS variables
- Important: Additional unit support:
vmax, and more
- Improved Flex Layout module support
While this isn’t the exhaustive list (we’ll provide that during a later beta phase, and in public docs upon release), it gives you a taste of what’s to come.
Early notice for developers with existing plugins
With each API update, we put a ton of work into ensuring backwards compatibility for existing plugins. The upcoming UXP update is no exception, and we’ll be introducing a compatibility mode to minimize the impact on existing plugins that don’t take advantage of the new features. This compatibility mode will be on by default for any plugin that isn’t updated to take advantage of the new API features.
If you’re already shipping an XD plugin and do plan on updating it to take advantage of the new API features, you should take special note of the bullets marked as Important in the lists above, as they could impact your UI layout when the API update ships.
A quick look at why for each:
From the list of new features:
Currently, UI layout in UXP doesn’t always behave as you would expect for all HTML elements. From our docs:
In XD, all elements use
blocklayout by default. … if the
inlineelement is desired, one can use the Flexbox layout system to simulate some
As a simple demonstration, consider the following simple HTML snippet.
Because of the new
display: inline semantics, this will render very differently between the current version of UXP shipping in XD today and version of UXP that will ship this summer. Here’s an example of the difference:
This improvement will allow improved plugin UI, including the following:
- Rich text on a single line (for example, you can emphasize a specific word or phrase)
- Reduced necessity to reach for flex just to position elements next to each other
We plan to be extremely proactive in reaching out to developers who might be affected by this in unexpected ways. If you want to get ahead, join our prerelease now — you’ll soon be able to check your plugins. We’re there in the prerelease forums to help.
Improved font rendering
Upcoming enhancements to font rendering can have an impact on a plugin’s layout by a few pixels here and there, so you may want to tweak your UI a little.
For example, let’s look at some text rendered in the current version of UXP (XD 18):
When the summer version of UXP is released, you’ll have text that looks like this:
Notice that, in particular, the kerning is slightly different. The difference is enough to change the example above from five lines of text to just four, and significantly changes the shape of the right edge. If you use ellipses or truncate text based on a specific width, you may want to adjust your breakpoints ever so slightly.
Additional unit support
From the list of updated features:
Additional unit support:
vmax, and more
Currently, UXP only supports two units:
%. If, for whatever reason, a unit was not specified, UXP currently assumes that you wanted your length to be based on pixels. As such, a style like
width: 100 would result in an element that was 100px wide. Let’s take a look at this in action:
The summer release of UXP will support many more units, and will behave closer to the standard when no unit is supplied (rather than inferring the
px unit). As such,
width: 100 may be interpreted very differently than you might expect. Here’s a preview:
Note that the first box is using
width: 100 and is definitely not 100 pixels wide. This is because the length value is being ignored. Because this element is rendered as a block, it expands to fill the width of its container. If this were an inline element, its width would only be as wide as needed to contain its text.
With these changes it’s important to be vigilant for:
- Units other than
pxused in your code that will soon be respected by the API
- Values in your code that should have a unit but either don’t, or are misspelled, and therefore invalid
Both of these situations may cause elements to be incorrectly sized, which could impact your UI layout.
Again, we plan to be extremely proactive in reaching out to developers who might be adversely affected by this. You can get ahead by joining our prerelease.
Panels: a new insertion point for plugins
When you create an Adobe XD plugin today, you have two options for surfacing your plugin to users:
- As a modal (which presents blocking UI to the user), or
- As a headless script (which presents no UI)
Modals are perfect for user workflows that follow a “configuration→execution→result” interaction model. Scripts are great for quick utilities that automate repetitive work.
But often the user workflow for a plugin is better suited for a “painter’s palette” style of interaction, where the plugin UI is persistent, enabling the user to access the plugin frequently and easily while working in the document.
The introduction of panels as an insertion point for XD plugins will make it possible for you to present plugin UI that sits to the side of the document in a brand-new Plugins Panel. Where modals have clear invocation boundaries that block the app UI until completion, XD panel APIs let you provide persistent UI while your plugin remains contextually aware and updated via lifecycle methods as the user works in the document.
Here’s a simple example:
Panels have been one of the most frequently requested additions to the API, and we’re really happy to be able to deliver this option to you soon.
Get involved: join the prerelease
XD plugin API alphas and betas are shared on the XD plugin developer prerelease.
To join and get access, email us at email@example.com. Once approved, you’ll need to sign an NDA, upon which you’ll get access.
Prerelease members get early builds with API changes, as well as a private community forum for discussions and code-level help from Adobe staff and other community developers.
It’s going to be a big summer for XD plugins and we hope you’ll take the journey with us!
Start by emailing us at firstname.lastname@example.org for prerelease access.