{
  "id": 11241291,
  "title": "An Icon API Should Be Able to Say “RTL Behavior Unknown",
  "url": "https://urgent.news/2026/10/01/an-icon-api-should-be-able-to-say-rtl-behavior-unknown",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-01T17:13:53.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/svgicons/an-icon-api-should-be-able-to-say-rtl-behavior-unknown-3fhp"
  },
  "original_language": "en",
  "account": "Right-to-left support poses a challenge for icon libraries. Some icons rely on reading direction, while others do not. Certain icons need distinct RTL assets instead of simple horizontal flips. However, when working with icons from various sources, there is an additional case to consider: what if the intended RTL behavior is not documented? For an icon aggregator, this should be a valid state rather than an invitation to guess. RTL support is not merely a rendering issue; it also involves deciding the appropriate semantic direction. While it may be tempting to treat right-to-left support at the CSS layer, this approach may be incorrect semantically. Icons representing navigation may need to change direction, whereas others should not. A list icon could require a different composition, and an icon containing letters or numbers might need a separate asset, as mirroring the SVG would also mirror its content. The core question is not whether an SVG can be flipped, but whether the icon was intended to change in an RTL interface. Some icon systems already encode this knowledge. Microsoft's Fluent UI System Icons include direction information in icon metadata, marking icons as mirrorable or having separate RTL and LTR versions. Wikimedia's Codex design system also documents that some icons should be mirrored, remain unchanged, or require dedicated RTL assets. For example, Codex treats icons representing horizontal direction or text differently from icons representing concepts such as time. The key takeaway is not that every icon library should use the same rules, but rather that different icon systems may make different decisions. When an icon service contains assets from multiple independent icon sets, an aggregator faces complications. Consider four source libraries: Set A explicitly documents RTL behavior, Set B provides separate LTR and RTL assets, Set C contains directional icons without metadata, and Set D says nothing about RTL. An aggregator cannot treat all four sources uniformly, as it may know the behavior for icons from Set A or Set B but not for icons from Set C or Set D. The aggregator should preserve this distinction in the import process. Unknown should be treated as valuable metadata, indicating that the source does not provide enough information to make a safe decision. Rather than returning only the directionality, an API could provide additional information about the source of the metadata. For instance, it could return: { directionality: { mode: 'mirror', source: 'upstream' } } or { directionality: { mode: 'unknown', source: null } }. This distinction makes it clear whether the original icon project specified the behavior, if it was added by the aggregation platform, if it was inferred, or if it was manually reviewed. This matters for APIs as well. When an application requests an icon, a direction-aware API could return metadata indicating the directionality mode and source. This information allows the consumer to make a deliberate decision about which icon to use. Furthermore, this becomes increasingly important when AI agents are selecting icons. For example, asking for a back action suitable for an Arabic interface requires access to directionality metadata to make an appropriate choice. By providing this metadata, icon APIs can empower developers and AI agents to make informed decisions about icon usage in different language contexts.",
  "summary": "Right-to-left support creates an interesting problem for icon libraries. Some icons clearly depend on reading direction. Others clearly do not. Some need a dedicated RTL drawing rather than a simple horizontal flip. But there is another case that matters when you work with icons from many different sources: What if nobody has documented the intended RTL behavior at all? For an icon aggregator,…",
  "key_points": [
    "Right-to-left support complicates icon libraries, some icons need distinct RTL assets.",
    "Icon aggregator must handle cases where RTL behavior is undocumented from various sources.",
    "An API should return directionality metadata indicating source of information, not just direction."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}