Skip to content

Ripple of InputElements should be triggered by HTMLLabelElement #5803

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bipedal-eel opened this issue May 12, 2025 · 5 comments · May be fixed by #5804
Open

Ripple of InputElements should be triggered by HTMLLabelElement #5803

bipedal-eel opened this issue May 12, 2025 · 5 comments · May be fixed by #5804

Comments

@bipedal-eel
Copy link

Description

According to the guidelines, or at least this gif:
https://m3.material.io/components/radio-button/guidelines#eba97636-1dd9-4e81-a1a6-20b8123d1b83
Image

The radio's label, or any input's label, should trigger the ripple effect. This is also something that the vanilla radio does:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/radio#try_it

Elements can also have multiple labels, so MdRipple.control should take in an array (or el | Array)

@asyncLiz
Copy link
Collaborator

Good find! It makes sense to me but I'll check with our designers to confirm that's the intention.

@asyncLiz
Copy link
Collaborator

Confirmed this is indeed a bug, though how to best fix it seems questionable.

I'm not sure I agree that a MdRipple.control should be an array, since it maps to the <md-ripple for="single-id"> attribute, and the htmlFor attribute is historically 1:1. It'd be more accurate to say that one control may have multiple ripples.

The ripple itself could try to check and handle a control's labels here to add events, but it wouldn't work for dynamic labels being added or removed to the control:

private onControlChange(prev: HTMLElement | null, next: HTMLElement | null) {
if (isServer) return;
for (const event of EVENTS) {
prev?.removeEventListener(event, this);
next?.addEventListener(event, this);
}
}

@bipedal-eel
Copy link
Author

htmlFor attribute is historically 1:1.

Mm yeah didn't think about that.

Wouldn't it make sense if all components that require a labelEl (i.e. radio, checkbox and switch) would implement the attachableController or rather extend a... lableHavingFormFieldAttchableController-Class since they would probably all do the same.

This could either take in the rippleEl and set the pressed and hoverer state, which have to be made public then.
Or a seperate lableControlledRippleEl and a set control to that.
Not sure which I'd prefer but probably the latter.

@asyncLiz
Copy link
Collaborator

Well it's not required that those components have a visual <label>. They can be standalone without a text label.

We could make something like the old <mwc-formfield> that's basically a fancy label, or an <md-label> element, but we lose that support for simple <label>-ability.

Native labels do some interesting things with CSS. They do trigger pseudo class styles. Hovering over this label example will cause the input to show a red outline (jsbin example). This works for form associated custom elements too.

<style>
  input:hover {
    outline: 1px solid red;
  }
</style>
<input id="checkbox" type="checkbox">
<label for="checkbox">Label</label>

Maybe there's a different approach to additionally support the ripple visual when its control matches :hover and :active without pointer events.

@bipedal-eel
Copy link
Author

bipedal-eel commented May 13, 2025

Tried this in the internal/_radio.scss and its working rather lovely:

:host(:hover) md-ripple {
  background-color: var(--md-ripple-hover-color);
  opacity: 0.08;
}

:host(:active) md-ripple {
  opacity: 0.12;
  transition-duration: 105ms;
}

initial thought is to use this map.get stuff to provide handling for the ripple which could be set here. Gotta do some reading about this though, my knowledge about scss is limited

Edit: went with @import ripple.controls: ripple.controls

Seems to work pretty well (I'm still testing around).
One side-effect is that the ripple animation wont work (the calculated stuff), though im not sure if thats needed for such small ripples... if it is needed one could probably check if pressed came from the AttachableController or the label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants