Version Packages

.changeset/modern-oranges-roll.md

@@ -1,5 +0,0 @@
----
-'@lion/ui': patch
----
-
-datepicker uses no calender-overlay-frame element anymore

.changeset/twelve-snakes-wait.md

@@ -1,28 +0,0 @@
----
-'@lion/ui': patch
----
-
-Overlay System uses `<dialog>` for top layer functionality of all overlays.
-This means overlays positioned relative to viewport won't be moved to the body.
-
-This has many benefits for the App Developer:
-
-- "context" will be kept:
-  - css variables and parts/theme will work
-  - events work without the need for "repropagation" (from body to original context)
-  - accessibility relations between overlay content and its context do not get lost
-- initial renderings become more predictable (since we don't need multiple initializations on multiple connectedCallbacks)
-- performance: less initialization, thus better performance
-- maintainability: handling all edge cases involved in moving an overlay to the body grew out of hand
-- developer experience:
-  - no extra container components like overlay-frame/calendar-frame needed that maintain styles
-  - adding a contentWrapperNode is not needed anymore
-
-There could be small differences in timings though (usually we're done rendering quicker now).
-Code that relies on side effects could be affected. Like:
-
-- the existence of a global Root node)
-- the fact that global styles would reach a dialog placed in the body
-
-For most users using either OverlayController, OverlayMixin or an element that uses OverlayMixin (like LionInputDatepicker, LionRichSelect etc. etc.)
-nothing will change in the public api.

.changeset/twenty-pigs-peel.md

@@ -1,5 +0,0 @@
----
-'@lion/ui': patch
----
-
-depend on @popperjs/core

packages/ui/CHANGELOG.md

@@ -1,5 +1,37 @@
 # @lion/ui
 
+## 0.0.10
+
+### Patch Changes
+
+- 36910e5d: datepicker uses no calender-overlay-frame element anymore
+- 64c0e26c: Overlay System uses `<dialog>` for top layer functionality of all overlays.
+  This means overlays positioned relative to viewport won't be moved to the body.
+
+  This has many benefits for the App Developer:
+
+  - "context" will be kept:
+    - css variables and parts/theme will work
+    - events work without the need for "repropagation" (from body to original context)
+    - accessibility relations between overlay content and its context do not get lost
+  - initial renderings become more predictable (since we don't need multiple initializations on multiple connectedCallbacks)
+  - performance: less initialization, thus better performance
+  - maintainability: handling all edge cases involved in moving an overlay to the body grew out of hand
+  - developer experience:
+    - no extra container components like overlay-frame/calendar-frame needed that maintain styles
+    - adding a contentWrapperNode is not needed anymore
+
+  There could be small differences in timings though (usually we're done rendering quicker now).
+  Code that relies on side effects could be affected. Like:
+
+  - the existence of a global Root node)
+  - the fact that global styles would reach a dialog placed in the body
+
+  For most users using either OverlayController, OverlayMixin or an element that uses OverlayMixin (like LionInputDatepicker, LionRichSelect etc. etc.)
+  nothing will change in the public api.
+
+- 00063d73: depend on @popperjs/core
+
 ## 0.0.9
 
 ### Patch Changes

packages/ui/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lion/ui",
-  "version": "0.0.9",
+  "version": "0.0.10",
   "description": "A package of extendable web components",
   "license": "MIT",
   "author": "ing-bank",