Hi. someone try enlighten me on this. Why does uxp input element add a padding top inside it’s input component and the inner background is slightly drained outside the border left and right . Technically I understand that all html input forms have an outline when on focus and this is for the accessibility issues but this with uxp is totally different and makes styling harder. The following images illustrate.
1)uxp without styling notice the left and right overflow
2)uxp with inner background set to white. notice the top and bottom padding.
would love to know how to work that out on a react environment. on vanilla environment like the above, you just using without installing anything. Like it works direct from the box like other html native elements?
Spectrum components are a confusing topic
As documentation, you’d better off referring mostly to this.
There are two flavours now, one is UXP widgets (stuff you can use in UXP without importing a single thing, just stick a <sp-textfield> in there and hope for the best) or UXP Spectrum Web Components (aka SWC: will need a manifest flag, and their support is still in its infancy).
You’ll may have more luck in terms of customisation with SWC, because UXP Widgets are mostly just bricks.
In the grand scheme of things, UXP SWC will comply with the kind of SWC you can read the documentation of here, while UXP Widgets have lived in isolation long enough to be their own species, in terms of API.
The good thing is that you can mix UXP Widgets and UXP SWC, but I haven’t been able to use SWC in React so far (I’m waiting for the new version’s docs) and the supports in terms of number of components is still very thin.
You can follow the progress here (which SWC is available)
Each supported component should comply with the respective, official SWC documentation here, provided the version matches.
I know this thread is three years old as of the date I write this reply. However, I cannot understand why we cannot control whitespace in an input field. It is virtually impossible to do this. I understand the need for Adobe to have third party apps conform to the hosts “look and feel” but the idea that we cannot control white space amounts within input items is a bit too heavy handed. In my case, when I insert a sp-textfield there is some really odd clipping going on. I presume its for some kind of iconography, but it’s always on the right side of the field — even when setting the “dir” attribute to “rtl”. It’s too rigid, and the fact that it’s not customizable is a problem for designers.
Look at these screenshots from two sp-textfield elements. One with the “dir” set to “rtl” and the other without it. It’s just abysmal. We cannot control absolutely anything about the placement of the user input text string. There is no way to center the text, there is no way to get rid of that weird padding / clipping thing going on in the right side of the element.
Also for numeric input you cannot also show more decimal places than 2. And some languages use different decimal separator . vs , and for the , it is broken and need additional handling.
You can get rid of the frame… you could try HTML atribute “quiet” or CSS appearance “none” or try input element instead sp-textfield
I tried implementing a regular field but no dice. Adobe’s Spectrum is too invasive. It doesn’t just override CSS, there is javascript that touches even the most basic HTML elements like .
I understand why they are so restrictive — they want third parties to conform not just to the “look and feel” but to the behavior of the widgets. However, Spectrum just doesn’t give enough flexibility. I mean, setting the justification of input text should be allowed. I guess those designers who build the design systems are adamant about their choices.
I think reason is something else. Scrollbars and inputs are not part of the HTML DOM. They are like C++ widget or layer above your plugin. That is why it has z-index infinity and beyond and no DIV can be above. This allows having dropdowns outside of the panel bounds. But at the same time introduces loads of quirks. And because it has different implementations, it cannot be implicitly connected with CSS styles, I guess.
