@fusion.dev/helix-docs 0.32.0 → 0.33.1

package/content/browser-support.mdx

@@ -49,6 +49,12 @@ they are load-bearing: the first is how every token expresses both color modes
 in one declaration, and the second is how every overlay is drawn in the top
 layer.
 
+Chromium 132 has both and still misses two things a page's stylesheet can say
+through `::part()`, measured 15 Sep 2026: it ignores a range input's
+`::-webkit-slider-thumb` and `::-webkit-slider-runnable-track` after a part, and
+it looks for the `@keyframes` a `::part()` rule names inside the component's
+shadow root, so no animation starts; the headless examples use neither.
+
 `:state()` is the third and is deliberately not with them, because it does
 degrade: a component that cannot record a state keeps whatever its resting rule
 draws, so a checkbox is drawn unchecked rather than drawn wrong or not at all.

package/content/charting.mdx

@@ -97,6 +97,32 @@ The legend reads the same table, so the names and the colors cannot disagree
 with the chart's. Pointing them at two different tables is the only way to make
 them disagree, and it is not something to do by accident.
 
+## Right-to-left
+
+On a page with `dir="rtl"`, an axis that follows reading order starts where the
+text does, on the right: categories and time. The words around a drawing are
+HTML and turn on their own, and the drawing turns with them, so the name under
+a column is that column's name in either direction. The pointer and the tooltip
+read the drawing the same way. An axis of values keeps its own direction.
+
+- **What turns.** `Bar Chart`'s columns, and its rows, which grow out of their
+  names at the right. `Line Chart`, `Area Chart` and `Sparkline`, with their
+  end marks. `Heatmap`'s weeks, which were already a grid laid out along the
+  line. A half `Donut Chart`, which is read across.
+- **What does not.** Up is more in every script, so values keep their vertical
+  sense, and numerals are text beside the drawing, so none reads backwards. A
+  whole `Donut Chart` keeps its first slice at twelve and runs clockwise, which
+  is a clock's convention rather than a script's. `Scatter Chart` is laid out as
+  on a left-to-right page, its y axis on the left and more to the right, because
+  both of its axes are measures and a number line runs that way in every
+  script. Its axis names read in their own direction, so a name in Arabic reads
+  right to left under the plot's far end, and its summary and tooltip read the
+  way the page does.
+
+A chart that should read left to right anyway, a number line in a mathematics
+text for instance, takes `dir="ltr"` on the element, and the platform's own
+attribute is the whole of the switch.
+
 ## Reduced motion
 
 Charts animate on entry and on data change, and every one of them answers

package/content/iconography.mdx

@@ -52,6 +52,20 @@ An icon with no `label` is hidden from assistive technology, which is right when
 the words are beside it and wrong when they are not. `Icon.Button` takes a
 `label` because it never has words beside it.
 
+## One that points along the line
+
+```html
+<helix-icon
+  mirror
+  name="arrow-right"
+></helix-icon>
+```
+
+The names are physical, so `arrow-right` points right on every page. An arrow
+that means forward or back asks with `mirror` to turn round on a right-to-left
+page, which every caret the library draws already does.
+[Localization](./localization) has the rest.
+
 ## Importing a glyph directly
 
 ```ts

package/content/localization.mdx

@@ -18,11 +18,42 @@ Set `dir` and the layout flips:
 ```
 
 Every component is written in logical properties, `inline-start` rather than
-`left`, `margin-block` rather than `margin-top`. Sixty-seven stylesheets name a
-direction, and **not one of them names a physical side**: there is no
-`margin-left`, no `padding-right` and no `inset-top` anywhere in the library.
-Nothing infers the direction for you and nothing needs to: the document says it
-and the components follow.
+`left`, `margin-block` rather than `margin-top`. Nothing infers the direction
+for you and nothing needs to: the document says it and the components follow.
+
+**A physical side appears only where the thing it places is physical.** A
+floating panel is placed from coordinates measured from the viewport's left
+edge, so it and its arrow are written in `left` and `top`. Everything a reader
+would expect to mirror still does.
+
+**Charts mirror too.** A category or time axis starts where the text does, so
+on a right-to-left page the first reading is on the right and the drawing,
+its labels, its hover targets and its tooltips all turn together. Values keep
+their vertical sense and numerals are not reversed. A whole donut stays
+clockwise from twelve, which is a clock's convention rather than a script's,
+and a scatter chart keeps its left-to-right plane, both of its axes being
+measures. [Charting](./charting) has the rest.
+
+**Carets and arrow keys turn too.** A caret meaning next or previous, the one
+between two crumbs and a shut disclosure all point along the line, so on a
+right-to-left page they point the other way, and every arrow key moves where it
+points on screen: the left arrow moves to the next tab, the next day, the next
+control in a toolbar, and opens a tree's branch or a menu's submenu, whose caret
+points left. A slider and a splitter's divider move the way the key points.
+
+A media player is an exception: its timeline and its skip buttons run left to
+right in every script, a tape having one direction, so the left arrow rewinds.
+A pin input is the other. A code is read like a phone number, so its boxes run
+left to right on every page: the first character typed goes in the leftmost
+box, a pasted code fills rightward and the right arrow moves on, while its
+label, hint and error read the way the page does.
+
+That is also how `placement` reads. The side is physical and the alignment is
+logical: `right` is the right of the anchor in either direction, and
+`bottom-start` lines a panel up with the anchor's start edge, which is its right
+edge on a right-to-left page. A panel with no room on its side still flips to
+the other one, so a `right-start` panel beside a rail at the start of a
+right-to-left page opens to its left.
 
 The same is true of anything you write on top. Use logical properties and your
 layout flips with ours; use `left` and `right` and it will not.
@@ -84,8 +115,20 @@ would be a second one to keep in step with yours.
   and font fallback all key off it.
 - **Numerals.** `Intl` handles the digits; a hardcoded `%` or a currency symbol
   in your own markup will not move to the right side.
-- **Icons that point.** A chevron meaning "forward" is mirrored by the logical
-  properties; one baked into an SVG path is not.
+- **Icons that point.** A caret a component draws turns on its own. An icon you
+  place does not unless you ask, because the names are physical: `mirror` turns
+  one on a right-to-left page, for an arrow that means forward or back.
+
+  ```html
+  <helix-button>
+    Continue
+    <helix-icon
+      mirror
+      name="arrow-right"
+      slot="end"
+    ></helix-icon>
+  </helix-button>
+  ```
 
 ## What is not covered