Thanks 
It would be really nice if there was a “linear” pdf manual that had a table of contents and went page by page… kind of like the old extendscript manuals. Trying to hunt around the websites is much more confusing, at least for me.
True. Hopefully there’s the Search tool
The flexibility is such a key factor for me, that’s why I used to create ALL my components from scratch.
Accordingly, I’m also not a huge fan of the plans to deprecate native form elements and force us to use Spectrum components.
The Div-Button will still work as divs are essential structuring tags that won’t be deprecated, but what about inputs etc.
For example, I’ve built a “UnitValueTextInput” component in the past, which allows to enter values like “10px”, “20mm” and validate or parse it accordingly. The flexibility to implement and style such custom components will be lost when there’s only Spectrum controls available…
Hi all –
A few replies to the various points raised in this thread; appreciate you all raising them.
[Space]/[Enter] handling
As far as I can see, most of this boils down to focus handling in Ps vs UXP. We know that this is not handled well at the moment, and there is work that is on-going to implement proper focus management so that Ps and UXP plugins can coordinate which one has focus. This will help address the issues here in that Ps would always be able to indicate that a button (of any flavor) in a panel shouldn’t steal focus when clicked, because canvas shortcuts should be preserved. There’s a lot of edge cases here to cover, so the work is pretty wide in scope. Please know, though, that we’re committed to addressing it in a way that preserves the host’s shortcuts.
As for [space] and [enter] being actions on a button – this behavior is typical and expected (and important from an accessibility standpoint) when it’s obvious the button is focused. These are shortcuts that people rely upon, and so we’re not going to remove handling like this on buttons. The issue here isn’t the shortcut, but two things: 1) it’s not obvious the button is still focused, and 2) the button shouldn’t have taken focus in the first place. Both of these are issues we’ll be addressing in UXP and PS with the focus management changes.
Deprecation of native widgets
Note that we don’t take this direction lightly. It is important to understand the history and context here, though, as to why this is important.
- Ps controls are largely all hand-drawn and rely upon their existing UI framework.
- This UI framework was never built with the expectation that you’d have web-like notions applied to these controls. This is why you have problems stacking elements on top of input fields or scrollbars – it was never a consideration in the past that this would ever be done.
- To address this issue, we’re moving to rendering controls using the OS’s native compositing engines. This will take considerable time to do, but will enable us to do things such as stacking items on top of input fields, proper opacity support, animations, and the like.
- The catch with moving to a new rendering engine is that those hand-drawn controls do not come with the transition. This means that our tradeoff is thus: in order to ensure that we can build a good foundation on which to render rich UI including transparency and animations and the like, we’ll end up sacrificing some of the existing UI widgets. (The reason Spectrum controls come along for the ride is because they are already built in such a way that avoids the issue – they’re using UXP at the C++ level to render controls.)
Deprecation will come in phases, with grace periods, and we will ensure that you can still do things such as wrap a Spectrum input in a custom component. So while that’s not possible today, we’ll make sure it is possible before we deprecate <input type="text">.
Docs/Search
We feel your pain here; the experience of using and searching our documentation is not what we would like. We’re pushing to get this improved, so hopefully you’ll start being able to have a better flow through the website in the future.
But, it’s also interesting that you bring up alternative formats like PDF. I wonder if there’s something we could do here, since it would also be useful in an offline capacity. Something for us to think about.
Thank you, @kerrishotts for these clarifications, very much appreciated.
This point below caught my attention:
Please, could you possibly give us a couple of exemples of those dand-drawn controls what would eventually become obsolete?
Thanks!
Thanks for the explanation. A couple of things I am still confused about though…
1, Once the bugs are fixed, what will the normal process be to make a button “in focus”? Does simply clicking a button cause it to be in focus and then be tied to the space and enter keys thereafter?
-
I realize the space and enter keys feature are going to stay. However, will there also be an option in the future for a button to not be tied to these keys? Will there be a different type of button or some way to opt-out of this feature for specific buttons?
-
For the div-button option mentioned in this post, is that particular div functionality going to also be deprecated? Since div tags themselves are going to remain, would this div functionality also remain? It was offered as an option to make a button from a div tag which wouldn’t be tied to the space bar or enter key. This sounds like a good solution if wanting to make a button not tied to the space bar or enter key.
All form elements. So: <button>, <input type="text|number|radio|range|checkbox">, <select>, <textarea>. Their Spectrum analogues are <sp-button>, <sp-textfield>, <sp-checkbox>, <sp-radio>, <sp-slider>, <sp-dropdown> (→ sp-picker in a future update), and <sp-textarea>.
It will be host and context specific. Buttons in panels shouldn’t take focus, for example, but they should in dialogs (so that you can use TAB to navigate). Text fields, however, should always take focus, because you’re now editing text.
You can intercept the focus event and call blur().
For example:
<sp-button nofocus>Hi</sp-button>
Array.from(document.querySelectorAll("[nofocus]:not([data-handler-added])"), el => {
el.addEventListener("focus", evt => evt.target.blur());
el.setAttribute("data-handler-added");
});
Once blurred, [SPACE] or [ENTER] will no longer invoke the button.
DIVs, SPANs, and events on those elements are not going away. They aren’t form elements, and they are handled by UXP’s rendering toolkit already. They get to come along for the ride to the new rendering engine. This means that you can always create faux buttons by styling DIVs. (I do suggest adding aria-role="button", though, for future accessibility.)
Thanks for the additional info
It sounds like when the bugs are fixed I can just continue to use the buttons as I am now since it isn’t dialog window.
Do you have any idea on a timeframe for a fix? If it is going to be many months then I may opt to convert to faux div buttons until the other buttons are fixed. However, if it is only a couple months or less then I’ll just leave the plugins as is.
Work is going on now in our codebase for focus management support. I hope it lands sooner rather than later, but you may want to be prepared for that not landing until a MAX release (Ps only has two more major release window vehicles: June/July and MAX).
If I were you, I’d add the snippet above that blurs when your buttons become focused, that way you can continue to use the buttons, but [SPACE]/[ENTER] won’t cause issues.
Thanks!!!
I just tested the snippet and it works perfectly. Not sure all of what all “blur” does. However, it works as you described without any other affects to the plugin as far as I can tell 
blur simply removes focus from the control. Think of it in terms of eyesight – focus is focusing attention onto something and blur is removing that focus. But I’ll admit that it’s a funky idiom in terms of keyboard navigation. 
So in the case of the above snippet, it’s essentially rejecting the focus request by blurring immediately. If you add a focus ring with *:focus { outline: 2px solid blue; }, you’ll see the focus being given for a split second (the focus ring appears) and then immediately revoked (the focus ring goes away).
2 Likes