Re: [heycam/webidl] WIP: add localizable dictionary (#358)

domenic commented on this pull request.



> +represents a bidirectional algorithm paragraph when displayed,
+as defined by the bidirectional algorithm’s rules P1, P2, and P3,
+including, for instance, supporting the paragraph-breaking behavior
+of <span class="char">U+000A LINE FEED (LF)</span> characters. [[!BIDI]]
+
+A user agent is expected to honor the Unicode semantics of [=localizable members=].
+
+The [=identifier=] of a [=localizable member=] is left to the defining specification (e.g., "title").
+
+Dictionaries that specify a [=localizable member=] must inherit from the {{Localizable}} dictionary.
+
+Specification authors must specify in prose which [=dictionary members|member(s)=]
+of the inheriting dictionary serve as [=localizable members=].
+
+Specification authors should limit the number of [=localizable members=] to one per dictionary,
+including in [=inherited dictionaries=] (if any).

In fact I'm pretty skeptical now of the web payments/notifications design of

```webidl
dictionary Thing : Localizable {
  DOMString title;
  // other members, hopefully not DOMStrings
}
```

The advantage is that authors have slightly less typing:

```js
const thing = {
  title: "foo",
  dir: "rtl"
};

// instead of

const thing = {
  title: { value: "foo", dir: "rtl" }
};
```

but the disadvantage is it means you can never add new string members to the dictionary without  running afoul of bad practice.

As such I think web payments should use my `LocalizableString` proposal instead of its dictionaries inheriting from `Localizable`. (In fact we can remove `Localizable` entirely and just have `LocalizedValue`.) We can then say Notifications' design is old-school.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/358#discussion_r114694151