e452a3285b
Eighteen icon components behind one barrel at shared/components/Icons. Every icon renders at 1em in currentColor and is aria-hidden, so size, colour and accessible naming all come from whatever contains it. The two link arrows carry motion. They are drawn as separate head and tail elements on purpose: the tail retracts to nothing while the head advances, which a single path cannot do, and a flattened replacement renders correctly while silently losing the animation. One inherited custom property is the whole contract: --xrpl-icon-engaged: 0 at rest … 1 engaged It names the cause rather than the effect. A container knows its own hover and focus states but not which icon it holds, so each icon decides what engagement means for it, and an icon with no stylesheet ignores the signal and stays static. Containers drive it with the xrpl-icon-engaged mixin, which emits `> .xrpl-icon` — one level, then stop. That is what keeps a hovered card from engaging the arrow inside a button it merely contains. Include it on the element the icon actually sits in, which is not always the element carrying the state; attached too high it matches nothing, which fails as a missing animation rather than a wrong one. The rest value declared on .xrpl-icon blocks a container that sets the property directly instead of using the mixin. Where the trigger is React state rather than a CSS state there is no pseudo-class to hang the mixin off, so the arrows take an optional `engaged` prop. Omitted it writes nothing at all; `false` is deliberately different, pinning the icon still. Fourteen of the icons are Google Material artwork under Apache-2.0. Each file names its exact upstream source and commit, and lists the modifications made to it; the licence entry is in LICENSE at the root. Adds /icon-demo as the reference page for the set. It is linked from nowhere and excluded from site search and sitemap.xml, but deliberately left out of redocly.yaml's ignore list, which would 404 it under `realm develop` too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
XRPL Dev Portal
The XRP Ledger Dev Portal is the authoritative source for XRP Ledger documentation, including the core server, client libraries, and other open-source XRP Ledger software.
The site is built and published using Redocly.
Before you proceed, make sure you have Node.js and NPM installed. The site is tested with the current LTS release of each.
To build the site locally:
-
Clone the repo and change into its directory:
git clone git@github.com:XRPLF/xrpl-dev-portal.git && cd xrpl-dev-portal -
Install Redocly Realm:
npm install @redocly/realm -
Switch to the
masterbranch if you aren't on it already.git switch master -
Build and start a local server:
npm start
For more details, see the contribution guidelines (EN) (日本語) and the contributor Code of Conduct (EN) (日本語).
Localization / Translations
The documentation in this repository is created in English first, then translated into other languages by community contributors. Currently, only the Japanese translations are live on the site; Spanish translation efforts are incomplete and not actively used. For information on the process of adding and maintaining translated files, see Translations.
Issues, Projects, and Project Boards
Use GitHub Issues under the xrpl-dev-portal repository to report bugs, feature requests, and suggestions for the XRP Ledger Documentation or the xrpl.org website.
For issues related to xrpld/rippled, Clio, or client libraries (xrpl.js, xrpl-py, and others), use the respective source repository under https://github.com/XRPLF.
If you are a contributor, use GitHub Projects and Project Boards to plan and track updates to xrpl.org.
Project Board xrpl-docs
The xrpl-docs Kanban board is used to plan and track updates to the XRP Ledger Documentation. Contributors must update the status of an issue as it progresses through different stages.
The xrpl-docs board has six columns based on the status of issues in this repository:
-
No Status: New or existing issues that no one has triaged yet.
-
Backlog: Issues that represent tasks to be done eventually. They should contain actionable and helpful information for a contributor to work on addressing the issue.
-
Planned: Issues with assignees who plan to address them in the near future, like 2-4 weeks.
-
In Progress: Issues that a contributor is actively working on.
-
In Review: Issues with a proposed fix that is currently being reviewed. These should be associated with an open pull request.
-
Done: Issues that have been completed, whose related content updates have been merged.