skill
Adom UI Design System
Public Made by Adomby adom
How the AI builds and tests interfaces people love to use in Adom. Ships as one installable skill that bundles focused skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths).
← Commit history
2.3.1 (doc only, module bytes unchanged): pane-minus-32 and 16px-a-side agree even with a scrollbar, because the check reads clientWidth
2 files changed
+7−1
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-ui-design",- "version": "2.3.0",+ "version": "2.3.1", "type": "skill", "description": "The Adom UI Design System plus a bundle of focused UI skills (tooltips, floating-windows, toasts, responsive-ui, app-shell, ai-driven-apps, clickable-paths, dark-default, input-feedback, settings-layout). One install drops the whole set of skill files onto your container, plus shared icon assets (the settings cog) so every Adom app draws the same glyph.", "dependencies": {},
skills/newbie-panel/SKILL.md+6@@ -307,6 +307,12 @@ So `selfCheck` now carries a **panel gutter** row, and it fails a panel that is built inside a wrongly padded page. Negative-tested in both directions before shipping: 50px a side goes red, 0px a side goes red, 16px a side passes, and it returns to green when restored. +**"Pane minus 32" and "16px a side" are the same rule, even when your page has a scrollbar.**+The check reads `document.documentElement.clientWidth`, which EXCLUDES the scrollbar, so on a+scrolling page where `innerWidth` is 744 and the usable width is 734, both formulations still+agree exactly. nb spotted the apparent 10px contradiction and went to the implementation+before arguing about it, which settled it in one read. Reason from the code, not the prose.+ If your page needs a wider margin for its own content, put it on the app body BELOW the panel, not on the container the panel mounts in. The panel is the full-width band at the top; the app's own gutter is the app's business.