The `useId` hook causes a re-render in TransitionChild immediately after mount which triggers a transition by `initial` being false in the second re-render regardless of how `appear` was set.
This commit also contains new code introduced after the PR in #853 was
merged. I just squashed it all together to prevent noisy commits to try
and fix CI.
The funny thing is that now the final commit looks fairly stupid/simple
but it wasn't that easy as I would have liked.
1. Couldn't find a proper way to execute `npm version` using yarn
workspaces. `yarn workspaces foreach npm version` would have worked
if we were using Yarn 2 instead of Yarn 1.
2. Introducing `version` and `publish` scripts in both packages worked,
but then the default `version` and `publish` were also executed.
3. Once I made the scripts unique (`npm-version`, `npm-publish`) it
worked~ish. The registry was always set to a yarnpkg registry, even
if we set the registry in CI and in a local .npmrc file. My guess is
that we are executing in a nested directory and therefore it didn't
work.
4. Next, I found the `npm workspaces` option so that we can use that in
addition to `yarn workspaces` 🙃
5. In CI of course this didn't work, because I was not using the same
node version...
6. After everything worked, I did cleanup of the new scripts, and
removed the introduced .npmrc files.
* fix broken `escape` key behaviour
We've "fixed" an issue when we had nested Dialogs ([#430](https://github.com/tailwindlabs/headlessui/pull/430)).
The `escape` would not close the correct Dialog. The issue here was with
the logic to know whether we were the last Dialog or not. The issue was
_not_ how we implemented the `close` functionality.
To make things easier, we moved the global window event to a scoped div
(the Dialog itself). While that fixed the nested Dialog issue, it
introduced this bug where `escape` would not close if you click on a
non-focusable element like a span in the Dialog.
Since that PR we did a bunch of improvements on how the underlying
"stacking" system worked.
This PR reverts to the "global" window event listener so that we can
still catch all of the `escape` keydown events.
Fixes: #524Fixes: #693
* update changelog
* Add Vue emit types
* ensure value is a boolean
Even though we only use `false` for now
* add Vue emit types for Tabs component
* update changelog
Co-authored-by: henribru <6639509+henribru@users.noreply.github.com>
* add `{type:'button'}` only for buttons
We will try and infer the type based on the passed in `props.as` prop or
the default tag. However, when somebody uses `as={CustomComponent}` then
we don't know what it will render. Therefore we have to pass it a ref
and check if the final result is a button or not. If it is, and it
doesn't have a `type` yet, then we can set the `type` correctly.
* update changelog
* expose a `close` function via the render prop for the `Popover` and `Popover.Panel` components (React)
* expose a `close` function via the render prop for the `Disclosure` and `Disclosure.Panel` components (React)
* expose a `close` function via the render prop for the `Popover` and `PopoverPanel` components (Vue)
* expose a `close` function via the render prop for the `Disclosure` and `DisclosurePanel` components (Vue)
* add `aria-orientation` to the Listbox component
By default the `Listbox` will have an orientation of `vertical`. When
you pass the `horizontal` prop to the `Listbox` component then the
`aria-orientation` will be set to `horizontal`.
Additionally, we swap the previous/next keys:
- Vertical: ArrowUp/ArrowDown
- Horizontal: ArrowLeft/ArrowRight
* update changelog
* add ability to use `Disclosure.Button` inside a `Disclosure.Panel`
If you do it this way, then the `Disclosure.Button` will function as a
`close` button.
This will make it consistent with the `Popover.Button` inside the
`Popover.Panel` funcitonality.
* update changelog
* change className to class
Co-authored-by: Ryan Johnston <ryan@magic.nz>
* drop className as a function in Vue
* update changelog
Co-authored-by: Ryan Johnston <ryan@magic.nz>
* encode expected `aria-expanded` behaviour
* ensure `aria-expanded` has the correct value
`aria-expanded` can be in 3 different states:
| Value | Description |
| ------------------- | -------------------------------------------------------------------------- |
| false | The grouping element this element owns or controls is collapsed. |
| true | The grouping element this element owns or controls is expanded. |
| undefined (default) | The element does not own or control a grouping element that is expandable. |
Ref: https://www.w3.org/TR/wai-aria-1.2/#aria-expandedFixes: #580
* ensure `disabled` prop in Vue is not rendered when `false`
* update changelog
Jonathan Reinink