Open/close design: Add more alternatives

[stasm]

We should document that we considered using the exact HTML syntax, either completely not supported or parsed as part of the message.

I'm filing this PR as a draft, please feel free to extend it.

[aphillips]

We should document that we considered using the exact HTML syntax, either completely not supported or parsed as part of the message.

We do support using the exact HTML syntax as "just a literal" because we support literal text. Nothing we do will prevent (or should prevent) people from writing messages like:

Hello <b>{$username}</b>!

or even:

Click <a href={$target}>here</a> to get {10 :percent} savings!

This has obvious problems for translators, for which a lot of tooling exists (but which could be considered less effective than something supported by the syntax). And it means different handling if you're running in JS. But it's not "wrong".

[aphillips]

I think it is useful to document these options.

[stasm]

This has obvious problems for translators, for which a lot of tooling exists (but which could be considered less effective than something supported by the syntax). And it means different handling if you're running in JS. But it's not "wrong".

Agreed. I wasn't trying to say that it was wrong, but instead I wanted to capture the discussion about why -- even if it's possible -- it's also not enough for some of our use-cases. The really interesting thing to me, however, is that a lot of use-cases that we listed in the doc can in fact be satisfied by the "do nothing" approach. This gives me pause.

Things start to get messy once we consider formatting to parts: Hello <b>, $username, </b>!. Even more so, when placeholders appear inside the HTML: Click <a href=, $url, >here</a> is really hard to parse.

Perhaps we're missing a few requirements?

[aphillips]

@stasm

Things start to get messy once we consider formatting to parts: Hello , $username, !. Even more so, when placeholders appear inside the HTML: Click <a href=, $url, >here is really hard to parse.

Actually, format-to-parts (FTP) and the "click" example is really interesting. FTP would make that into three parts:

Click <a href="
{$url}  // as evaluated at runtime
">here</a>

The two text fragments cannot be turned into HTML cleanly on their own--only when the whole <a> tag is reassembled does it make sense. This is a case where spannables might provide something better than "do nothing"

Perhaps we're missing a few requirements?

Maybe, but maybe not.

The compromise in Seville was basically: no operands, no to-string interpretation by default (implementations may provide one). Not everyone agrees about the need for or importance of spannables nor about how to handle spannables. Implementations that don't support spannables could evaporate them in FTP or, as Eemeli suggests, return a "part" that the consumer can do whatever they want with.

One thing I kind of like about the proposal is that it can support straightforward conversion to HTML/DOM without resorting to a registry of tags (there is no need to list the supported tags): the "function" is the HTML tag and the options are the attributes. You can create a DOM node out of it and fill it with content ("parts") until you see the close. You can call getParent when you see that close to restore state--the DOM provides the nesting for free. At the same time, it can also support Mihai's desire for attributed strings. MF2 doesn't care about validity.

[eemeli]

I'd like for us to merge this, as it finally reflects the starting point for last week's deliberations. Then I can file another PR on top of this that reflects the results of those deliberations, and the preliminary consensus on {#foo}...{/foo} that we reached last week.

@aphillips Your change-requested review is blocking my ability to merge this, as I don't have admin access. Could you do it? We can still iterate on the doc in the next PR.

[aphillips]

@eemeli Done