Sebastian "Sebbie" Silbermann

> I'm willing to move the typings back into our repo as separate .d.ts files to start. *the crowd cheers* > Who wants to work on the first phase? *the...

Why should `ByRole` throw? There's a `textbox` with the name `Name: `. `ByLabelText` seems to not recognize `` as a form control though it's unclear why. `` is equivalent to...

`aria-labelledby` is ignored if it's invalid. I don't understand why this should affect if an element is considered a form control or not.

> So then `ByLabelText` should be adjusted to ignore invalid `aria-labelledby`, right? If they want to implement `accname` in that regard, yes. But `ByLabelText` is not equivalent to `ByRole#name` so...

I think we want to encourage `getByRole('button', { name: 'Hello' })` for these specific examples. I think this should be preferred for most use cases but I'd be interested in...

> This happened on v4 and v5 of this library. Is it supposed to work? Possibly if there are indeed multiple elements with that role and name. But this was...

> The name spec is hard to read, but it looks like it could cover the button-specific use case. You don't actually need to read it but rather know what...

> I also like to separate selectors from assertions for specifications. Sure. But this looks like you want to assert on the accessible name. I think getting it by test-id...

> expect(button).toHave[Accessible]Name('Page 1') That is what I do personally but this repository is not concerned with matchers. As you said: You want to decouple matchers from getters.

I don't follow what the issue is now. The button examples you gave in the opening post can switch to `*ByRole` + `name` which has an official spec. `*ByDisplayValue` is...