Sebastian "Sebbie" Silbermann

Perfect. This is indeed a bug. We're currently assuming that `visibility` acts like `display`. While `display: none` hides any child even if they do set `display: block`, `visibility: hidden` can...

> getComputedStyle brings visible for the strong and p elements even if the property is not set. It should've brought hidden because it inherits. Which jsdom version are you using?...

> @eps1lon are you sure CSS inheritance is working? For `visibility`, yes. Seems to be that inline styles are ignored for inheritance. For declaration it's working: https://runkit.com/eps1lon/5e4ea8c4d54b2400136cd768

I prefer additional tests over changing existing ones. This way we make sure we don't regress.

Write two tests then and comment the wrong one properly so that it is obvious that it will break once jsdom is fixed.

> Is there any update on this, or a workaround. I've posted a CodeSandbox with minimal code on StackOverflow reproducing the issue > [stackoverflow.com/questions/62427793/isvisible-doesnt-work-in-jest-test-using-jest-dom](https://stackoverflow.com/questions/62427793/isvisible-doesnt-work-in-jest-test-using-jest-dom) That stackoverflow question is about `opacity`...

If I remember correctly there wasn't much to it. 1. Add types to the original repository (SemVer minor) 2. Remove types from DefinitelyTyped

I want to share a case related to focus events. If you have a non-focusable element e.g. `` you can `div.dispatchEvent(new FocusEvent('focus'))` and any focus event listener on the div...

We definitely want to document a good pattern for testing errors. But this should cover components as well not just hooks.

> I agree with [perymimon](https://github.com/perymimon), you don't need to wait to have a component error resolution to raise the hooks error resolution. The problem is that without understanding the problemspace...