considering using a namespace for fluent attributes (directives) instead of prefix

[caridy]

Many new frameworks are relying on directives rather than prefixing attributes. e.g.:

<p data-l10n-foo="x">
vs 
<p l10n:foo="x">

The benefit here is that namespacing the attribute can have a very specific meaning, including the ability to not really adding it to the DOM. While using data- could probably conflict with data attributes, which will force you to add it to the Element in the DOM, which will imply a perf penalty for something that doesn't really have to go to the DOM.

Additionally, there is a proposal for HTML to claim namespaces for attributes, which might help in the long run to apply special behavior to new custom elements who are receiving attributes with the corresponding namespace.

[stasm]

The data-l10n-* prefix is specific to the fluent-dom bindings. There are two things that bindings need to do:

• translate the UI the first time (or when the language changes),
• react to changes in the UI and reformat translations if arguments change.

In case of regular DOM elements, for both of these objectives we need some logic external to the elements themselves. For the initial translation, we use querySelector('[data-l10n-id']) to collect the list of all localizable nodes. For reactivity, we use a MutationObserver with attributeFilter: ['data-l10n-id'] to react to changes of attributes and retranslate elements.

I'd much prefer using namespaces. Sadly, neither querySelector nor MutationObserver currently support namespaces in attributes names.

Other implementations may choose different schemes for bindings elements to their localization. For instance in fluent-react we use the <Localized id="foo"> component. The component implements its own initialization logic which solves the problem of the initial translation. OTOH, React solves the other problem by rerendering components when their propos change.