smartrte-react 1.0.0-beta.12 → 1.0.0-beta.14

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (6) hide show
  1. package/CHANGELOG.md +8 -0
  2. package/LICENSE +21 -0
  3. package/README.md +239 -750
  4. package/dist/components/fixedPositioning.d.ts +42 -9
  5. package/dist/components/fixedPositioning.js +47 -11
  6. package/package.json +1 -1
package/dist/components/fixedPositioning.d.ts CHANGED
@@ -9,11 +9,40 @@
9
9
  * (`translate-x-[-50%] translate-y-[-50%]`), confirmed live via a Sootr
10
10
  * host rendering the editor inside such a dialog
11
11
  * (docs/bugs/toolbar-menu-misplaced-inside-transformed-ancestor.md).
12
- * - `contain: paint | strict | content` (CSS Containment) - a common
13
- * perf/isolation optimization on large scrollable containers, e.g. a
14
- * second, different Sootr dialog reported still misplacing every toolbar
15
- * dropdown ("More list tools", "More to insert", "Save a copy", "More
16
- * text styles") despite already running the transform-only fix above.
12
+ * - `translate`, `rotate`, `scale` (CSS Transforms Level 2's *independent*
13
+ * transform properties, distinct from the legacy composite `transform`
14
+ * property) - a FOURTH real Sootr dialog kept misplacing every dropdown
15
+ * after all three fixes above shipped, still using the exact same
16
+ * `translate-x-[-50%] translate-y-[-50%]` Tailwind centering classes the
17
+ * very first fix (above) was written for - but a current Tailwind/browser
18
+ * combination compiles those classes to the standalone `translate: -50%
19
+ * -50%` CSS property, not `transform: translate(-50%, -50%)`. Confirmed
20
+ * directly in real Chromium: an ancestor with only `translate` set (its
21
+ * own computed `transform` reads `none`) still fully establishes a
22
+ * `position: fixed` containing block, per the CSS Transforms Level 2
23
+ * spec - the original fix's own doc comment described the right *symptom*
24
+ * (a Radix/shadcn Dialog's centering translate) but checked the wrong
25
+ * *property* for it, because at the time it was written the transform
26
+ * ended up composited into `transform` rather than emitted as `translate`
27
+ * directly. Both are checked now, since either can appear depending on
28
+ * the host's exact Tailwind/browser version.
29
+ * - `contain: layout | paint | strict | content` (CSS Containment) - a
30
+ * common perf/isolation optimization on large scrollable containers, e.g.
31
+ * a second, different Sootr dialog reported still misplacing every
32
+ * toolbar dropdown ("More list tools", "More to insert", "Save a copy",
33
+ * "More text styles") despite already running the transform-only fix
34
+ * above. `layout` alone (without `paint`) was missed in that first pass -
35
+ * only checked for `paint`/`strict`/`content` - and confirmed directly in
36
+ * real Chromium to establish the containing block on its own regardless:
37
+ * a `position: fixed` descendant of a bare `contain: layout` ancestor (no
38
+ * transform, no paint) resolves its `top`/`left` against that ancestor's
39
+ * box, not the viewport. A THIRD Sootr dialog using exactly this
40
+ * (`contain: layout`, no `paint`) reported the same misplacement symptom
41
+ * again - not a clipping/invisibility symptom (see `getPositioningBounds`
42
+ * below for that distinct failure mode), just landing in the wrong place
43
+ * with no error, since the previous check silently treated this ancestor
44
+ * as if it weren't a containing block at all and fell through to
45
+ * `{ left: 0, top: 0 }` (viewport-relative) origin math instead.
17
46
  *
18
47
  * Deliberately NOT checking bare `container-type` (CSS Containers) -
19
48
  * despite implying `contain: layout style` per spec, verified directly in
@@ -57,10 +86,14 @@ export declare function getFixedPositioningOrigin(el: HTMLElement): {
57
86
  * the actual, much narrower, clipping ancestor.
58
87
  *
59
88
  * Deliberately NOT applied for a containing block established only by
60
- * `transform`/`perspective`/`filter`/`backdrop-filter`/`will-change` with
61
- * no `contain` of its own - none of those clip overflow, so a menu is free
62
- * to visually extend past that ancestor's box exactly as it could before
63
- * any of this positioning logic existed. Verified directly: constraining
89
+ * `transform`/`translate`/`rotate`/`scale`/`perspective`/`filter`/
90
+ * `backdrop-filter`/`will-change`, or by `contain: layout` with no
91
+ * `paint`/`strict`/`content` alongside it - none
92
+ * of those clip overflow (`layout` containment only isolates layout
93
+ * calculations, it does not imply paint containment - see the spec note
94
+ * above `findFixedPositioningContainer`), so a menu is free to visually
95
+ * extend past that ancestor's box exactly as it could before any of this
96
+ * positioning logic existed. Verified directly: constraining
64
97
  * to such an ancestor's bounds regardless made a mobile "More tools" menu
65
98
  * genuinely too tall to fit inside a short transformed host overlap its
66
99
  * own trigger instead of just extending past the host's edge (harmless,
package/dist/components/fixedPositioning.js CHANGED
@@ -9,11 +9,40 @@
9
9
  * (`translate-x-[-50%] translate-y-[-50%]`), confirmed live via a Sootr
10
10
  * host rendering the editor inside such a dialog
11
11
  * (docs/bugs/toolbar-menu-misplaced-inside-transformed-ancestor.md).
12
- * - `contain: paint | strict | content` (CSS Containment) - a common
13
- * perf/isolation optimization on large scrollable containers, e.g. a
14
- * second, different Sootr dialog reported still misplacing every toolbar
15
- * dropdown ("More list tools", "More to insert", "Save a copy", "More
16
- * text styles") despite already running the transform-only fix above.
12
+ * - `translate`, `rotate`, `scale` (CSS Transforms Level 2's *independent*
13
+ * transform properties, distinct from the legacy composite `transform`
14
+ * property) - a FOURTH real Sootr dialog kept misplacing every dropdown
15
+ * after all three fixes above shipped, still using the exact same
16
+ * `translate-x-[-50%] translate-y-[-50%]` Tailwind centering classes the
17
+ * very first fix (above) was written for - but a current Tailwind/browser
18
+ * combination compiles those classes to the standalone `translate: -50%
19
+ * -50%` CSS property, not `transform: translate(-50%, -50%)`. Confirmed
20
+ * directly in real Chromium: an ancestor with only `translate` set (its
21
+ * own computed `transform` reads `none`) still fully establishes a
22
+ * `position: fixed` containing block, per the CSS Transforms Level 2
23
+ * spec - the original fix's own doc comment described the right *symptom*
24
+ * (a Radix/shadcn Dialog's centering translate) but checked the wrong
25
+ * *property* for it, because at the time it was written the transform
26
+ * ended up composited into `transform` rather than emitted as `translate`
27
+ * directly. Both are checked now, since either can appear depending on
28
+ * the host's exact Tailwind/browser version.
29
+ * - `contain: layout | paint | strict | content` (CSS Containment) - a
30
+ * common perf/isolation optimization on large scrollable containers, e.g.
31
+ * a second, different Sootr dialog reported still misplacing every
32
+ * toolbar dropdown ("More list tools", "More to insert", "Save a copy",
33
+ * "More text styles") despite already running the transform-only fix
34
+ * above. `layout` alone (without `paint`) was missed in that first pass -
35
+ * only checked for `paint`/`strict`/`content` - and confirmed directly in
36
+ * real Chromium to establish the containing block on its own regardless:
37
+ * a `position: fixed` descendant of a bare `contain: layout` ancestor (no
38
+ * transform, no paint) resolves its `top`/`left` against that ancestor's
39
+ * box, not the viewport. A THIRD Sootr dialog using exactly this
40
+ * (`contain: layout`, no `paint`) reported the same misplacement symptom
41
+ * again - not a clipping/invisibility symptom (see `getPositioningBounds`
42
+ * below for that distinct failure mode), just landing in the wrong place
43
+ * with no error, since the previous check silently treated this ancestor
44
+ * as if it weren't a containing block at all and fell through to
45
+ * `{ left: 0, top: 0 }` (viewport-relative) origin math instead.
17
46
  *
18
47
  * Deliberately NOT checking bare `container-type` (CSS Containers) -
19
48
  * despite implying `contain: layout style` per spec, verified directly in
@@ -40,11 +69,14 @@ export function findFixedPositioningContainer(el) {
40
69
  while (node) {
41
70
  const style = window.getComputedStyle(node);
42
71
  if ((style.transform && style.transform !== "none") ||
72
+ (style.translate && style.translate !== "none") ||
73
+ (style.rotate && style.rotate !== "none") ||
74
+ (style.scale && style.scale !== "none") ||
43
75
  (style.perspective && style.perspective !== "none") ||
44
76
  (style.filter && style.filter !== "none") ||
45
77
  (style.backdropFilter && style.backdropFilter !== "none") ||
46
- (style.willChange && /transform|perspective|filter/.test(style.willChange)) ||
47
- (style.contain && /\b(paint|strict|content)\b/.test(style.contain))) {
78
+ (style.willChange && /transform|perspective|filter|translate|rotate|scale/.test(style.willChange)) ||
79
+ (style.contain && /\b(layout|paint|strict|content)\b/.test(style.contain))) {
48
80
  return node;
49
81
  }
50
82
  node = node.parentElement;
@@ -75,10 +107,14 @@ export function getFixedPositioningOrigin(el) {
75
107
  * the actual, much narrower, clipping ancestor.
76
108
  *
77
109
  * Deliberately NOT applied for a containing block established only by
78
- * `transform`/`perspective`/`filter`/`backdrop-filter`/`will-change` with
79
- * no `contain` of its own - none of those clip overflow, so a menu is free
80
- * to visually extend past that ancestor's box exactly as it could before
81
- * any of this positioning logic existed. Verified directly: constraining
110
+ * `transform`/`translate`/`rotate`/`scale`/`perspective`/`filter`/
111
+ * `backdrop-filter`/`will-change`, or by `contain: layout` with no
112
+ * `paint`/`strict`/`content` alongside it - none
113
+ * of those clip overflow (`layout` containment only isolates layout
114
+ * calculations, it does not imply paint containment - see the spec note
115
+ * above `findFixedPositioningContainer`), so a menu is free to visually
116
+ * extend past that ancestor's box exactly as it could before any of this
117
+ * positioning logic existed. Verified directly: constraining
82
118
  * to such an ancestor's bounds regardless made a mobile "More tools" menu
83
119
  * genuinely too tall to fit inside a short transformed host overlap its
84
120
  * own trigger instead of just extending past the host's edge (harmless,
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "smartrte-react",
3
- "version": "1.0.0-beta.12",
3
+ "version": "1.0.0-beta.14",
4
4
  "description": "A powerful, feature-rich Rich Text Editor for React with support for tables, mathematical formulas (LaTeX/KaTeX), and media management",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",