Test checking the markup arguments

[mihnita]

In u-options.json we have the following test case:

{
  "src": "{#tag u:dir=rtl u:locale=ar}content{/ns:tag}",
  "exp": "content",
  "expErrors": [{ "type": "bad-option" }, { "type": "bad-option" }],
  "expParts": [
    {
      "type": "markup",
      "kind": "open",
      "name": "tag"
    },
    {
      "type": "literal",
      "value": "content"
    },
    {
      "type": "markup",
      "kind": "close",
      "name": "ns:tag"
    }
  ]
},

I think there should not be any error here.

Implementations are free to use markdown as needed, as friendly as possible for the environment where they are used.
The markdown is largely left unspecified.
We don't say what options are valid or not.

I guess in the test above the expErrors is caused by u:dir=rtl and u:locale=ar?
These are in fact very useful options to have in markdown.
If one uses the MF2 markdown to produce html then these options map very naturally to dir and lang.

[eemeli]

Isn't the cause of the error clearly specified in the u:dir and u:locale descritions?

[mihnita]

Isn't the cause of the error clearly specified in the u:dir and u:locale descritions?

Yes:

If this option is set on markup, a Bad Option error is emitted
and the value of the u:locale option is ignored.
...
If this option is set on markup, a Bad Option error is emitted
and the value of the u:dir option is ignored.

But I am arguing that it's not a good thing.

Read the use case I described.

If I want to produce HTML from the MF2 markup then being able to specify a locale (mapping to html lang) and a direction (mapping to html dir) would be beneficial.

At this point markup is very much "free for all", and allows for almost anything.
Kind of weird to not allow these options. Especially since they seem to actually have good use cases.

Why are they considered "bad option"?

[eemeli]

This was discussed in #846 (comment) and #846 (comment).

[mihnita]

This was discussed in #846 (comment) and #846 (comment).

I don't think the threads actually closed with a conclusion.
Only "This is now an error." added 2 months later, and nobody protested, but I don't necessarily see consensus / agreement.

Fair enough, a decision had to be made.

But the PR ends with
"In the 2024-10-21 call we merged this so that it is visible in the spec. Open issues against the results if iteration is needed."

This is such an issue, opened against.

[eemeli]

This is such an issue, opened against.

In that case, could you retitle this issue as such, rather than as an issue about markup tests?

I don't think the threads actually closed with a conclusion. Only "This is now an error." added 2 months later, and nobody protested, but I don't necessarily see consensus / agreement.

Note that in #846 (comment) I explicitly ping'd you for comment, given your prior interest in the topic, and the thread was only closed two months after no comment on it.

In any case, my core rationale for the current solution is that u:dir and u:locale are special in how they affect the formatting context. if the formatting target is HTML, then an output element's dir and lang are not special, and can be used directly in the markup. Applying a mapping from u:dir to dir and/or u:locale to lang would make it appear as if the formatting context changes would also apply to content after a markup-start in the message, as I present in #846 (comment). That would be misleading to developers and translators.

[aphillips]

@mihnita Are you okay moving this to 48?

[mihnita]

Note that in #846 (comment) I explicitly ping'd you for comment, given your prior interest in the topic, and the thread was only closed two months after no comment on it.

Not accurate.

There are two comments that I added after you pinged me.
None of them sound like an approval.

@mihnita Are you okay moving this to 48?

Do I have a choice? :-)

Is there a 47.1 or something else before 48?

If not, then yes, fine.
Which does not mean I drop the issue.

[mihnita]

Note that the PR mentioned says

Note that u:locale and u:dir are ignored when used on markup.

The whole discussion was around that.

And the PR was closed with "This is now an error." without any discussion about it.
Being an error is not the same as "ignored".

[aphillips]

(chair hat)

There is no 47.1 planned, so 48 is the next release after 47. If you think this is a blocker for v47, now's the time to mark it as such 😉

Please note that I am not asking you to close this issue.