Is there a way to access autocomplete styles?

Even with &:autofill selector added the styles won't change.

Hmmm, yeah, I see now that the autocomplete attribute on combobox and textfield doesn't work as I would have expected it to. We still need to be able to apply those autocomplete styles though.

Looking at Web Components and React's implementations as well as MDN, it seems like maybe we'd want aria-autocomplete="list" instead? That seems to be the one that's turned on when autocomplete is working.

I don't see any added styles in index.css related to the design spec'd colors for autocomplete/autofill, did you add any? We should still have some way to make the autocomplete styles visible even if we don't implement any autocomplete functionality here so that SWC would be able to apply those autocomplete styles eventually.

My best guess would be to apply a selector like

.spectrum-Combobox-input[aria-autocomplete="list"] {
  /* Your autocomplete-specific styles here */
}

And then wire up an autocomplete Storybook control that would apply this attribute to the input, and then therefore apply the styles? Would that work?

Here's another thing about combobox that I'm wondering about that I sort of touched on in another comment: Should the min-inline-size be set on .spectrum-Combobox or on .spectrum-Combobox-input? When we have a side label the input tends to shrink a lot, in this case it's about 78.5px. Since the minimum width token is a multiplier (2.5 * the height, which is 32px), it looks like for this particular size the combobox should be a minimum of 80px. Which it is, if we're talking about the field label + input width, but the input is smaller. I know this is how it was before, but was that what was intended?

@rise-erpelding Looking at the component a little closer in Figma, it looks like side label and the input are half of the combobox in width.

@aramos-adobe I placed a min inline size of 50% for both label and the content (parent containing the inputs). I have seen any weird movements yet in the button. I did place a position: relative on the .spectrum-Combobox-content to keep the button at the end of it.

I think the 50% min sizing helps (textfield also has its own similar min sizing calc on the input, which helps here too) and that does match the way they're doing it in the Desktop Figma side label variants I see there, but the way I understood that combo-box-minimum-width-multiplier token to work is that it applies to the textfield input or any element that's the same width as the input, such as .spectrum-Combobox-content. Instead you have the combo-box-minimum-width-multiplier token on --spectrum-combobox-min-inline-size and then it's applied to .spectrum-Combobox, which includes the width of the input but also the width of the label.

I only see one instance where that's violated: XL(mobile), where the component height is 60px, so the min-width should be 60 * 2.5 = 150px but the component is just a few px shy of meeting that min-width.

Is there a reason why we subtract the border-width here? It looks like inline edge to start should start at the inside of the border instead of outside of it.

Firefox

I'm wondering if this is maybe mislabeled in the token spec, in the Desktop spec it looks like the inline and block spacing does include the border width 🤷‍♀️

@saashapina @rise-erpelding, I deconstructed the component in Figma and even if you remove the border it's still using the edge-to-text token regardless. The border/stroke line position is set to center of the combobox so it's going all the way to the edge.

To recap: @aramos-adobe and I talked this through and decided that the token spec is wrong and that the padding should be including the border (so the spacing is from the edge including the border), and therefore it does still need the calc to add only the spacing we need that isn't taken up by the border width.

I also noticed on the invalid tests when the combobox is expanded on size small there is a little bit of overlap with the fields below it, I'm not sure if its related to these changes or if this was an existing bug.
Medium

Large

@saashapina It's like this on the Picker as well and any other component using the Popover. Maybe this could a bug worth reporting in the future.

I'm wondering if this is maybe mislabeled in the token spec, in the Desktop spec it looks like the inline and block spacing does include the border width 🤷‍♀️

It looks like textfield is already making the same calculation with the border so it's being subtracted twice when used in the textfield input:

I think the 50% min sizing helps (textfield also has its own similar min sizing calc on the input, which helps here too) and that does match the way they're doing it in the Desktop Figma side label variants I see there, but the way I understood that combo-box-minimum-width-multiplier token to work is that it applies to the textfield input or any element that's the same width as the input, such as .spectrum-Combobox-content. Instead you have the combo-box-minimum-width-multiplier token on --spectrum-combobox-min-inline-size and then it's applied to .spectrum-Combobox, which includes the width of the input but also the width of the label.

I only see one instance where that's violated: XL(mobile), where the component height is 60px, so the min-width should be 60 * 2.5 = 150px but the component is just a few px shy of meeting that min-width.

Hmmm, yeah, I see now that the autocomplete attribute on combobox and textfield doesn't work as I would have expected it to. We still need to be able to apply those autocomplete styles though.

Looking at Web Components and React's implementations as well as MDN, it seems like maybe we'd want aria-autocomplete="list" instead? That seems to be the one that's turned on when autocomplete is working.

I don't see any added styles in index.css related to the design spec'd colors for autocomplete/autofill, did you add any? We should still have some way to make the autocomplete styles visible even if we don't implement any autocomplete functionality here so that SWC would be able to apply those autocomplete styles eventually.

My best guess would be to apply a selector like

.spectrum-Combobox-input[aria-autocomplete="list"] {
  /* Your autocomplete-specific styles here */
}

And then wire up an autocomplete Storybook control that would apply this attribute to the input, and then therefore apply the styles? Would that work?

To recap: @aramos-adobe and I talked this through and decided that the token spec is wrong and that the padding should be including the border (so the spacing is from the edge including the border), and therefore it does still need the calc to add only the spacing we need that isn't taken up by the border width.

Oh I'm so pumped for these styles! I also totally missed that it gets a color background (but I see that now in the Desktop spec), that was left out of the token spec, wasn't it?

A couple of small thoughts I have on this:

• The border color should be set here, gray-800 for autocomplete.
• Invalid border color also has tokens for the autocomplete state, but... it's the same as default so I don't think you need to add anything for that.
• Since we're setting box-shadow and not background-color for the background color, I don't know that the transition is doing much here. It's also a really long transition!
• Using box-shadow is a great hack here! Looking at the autocomplete state in the Desktop spec, it looks like only the highlighted text (would that be ::selection? honestly not sure) is meant to be that blue color? What if we set the box-shadow color to gray-25 (to override the user agent bg color) and then add a selector for ::selection, something that's maybe like this? (There are probably better custom props to use but just to give an example)

	&:-webkit-autofill,
	&:-webkit-autofill:hover,
	&:-webkit-autofill:focus,
	&:-webkit-autofill:active,
	&:-internal-autofill-selected,
	&.spectrum-Combobox-autocomplete {
		border-color: var(--spectrum-gray-800);
		box-shadow: 0 0 0 30px var(--spectrum-gray-25) inset !important;
		transition: background-color 5000s ease-in-out 0s; /* not sure about keeping this I'm just leaving it alone for now */
		-webkit-text-fill-color: var(--spectrum-neutral-content-color-default) !important;

		&::selection {
			background-color: var(--spectrum-combobox-background-color-autofill);
		}
	}

It's still a little problematic because the design shows something like this:

And that code would show something like this but only if you highlight it, which I assume you could do programmatically:

If our line-height is set to the component height it doesn't fully match, but I think we would want that line-height set to the component height so I'm not sure what the right answer is there.

I think either way this is going to need some adjusting when the component or the autocomplete feature is actually being built out, but it's a start... what are your thoughts?

Whatever you decide, just one more note to double-check it in WHCM, currently it looks like this:

Hmmm, this autocomplete is starting to be a little problematic... here are some thoughts/questions I have now:

• Should we use a custom property for the border instead of --spectrum-gray-800? We have --spectrum-combobox-border-color-default, --spectrum-combobox-border-color-hover, etc. that we already use, for instance.
• I think 5000s is a bit long for an animation-duration, although it is true that we have no guidance for this (I'm also not seeing this doing much of anything either way?).
• We also have no guidance for WHCM, but I'm guessing it might be jarring to enforce the white background color that I'm seeing now when all the others are dark.
• Changing the line-height for autofill only does make the highlight work as intended, but we'll still get cutoff for Thai in that case.
  

I'd initially only seen the autocomplete styles for border and text color, and hadn't seen the other spec where we're doing the highlight things... I'm kind of inclined to say that since trying to implement the highlight is causing a lot of issues + we also don't have great guidance for it now + at least in my opinion, we'd want to style this in a way that we know will be compatible with SWC, I'd be ok with only styling what's on the token spec (border and text color) and leaving this background-color/highlight portion alone for now, what are your thoughts?