I think we should require more spaces; see line comments for specifics. My opinions here are not set in stone, but I would prefer a bit more weight to be placed on the reader experience. So while e.g. match{$foo}{$bar} is easily parsable by a machine, I would maintain that a human would find match {$foo} {$bar} faster to understand. As with all code, people will spend far more time reading rather than writing MF2.

I agree with the sentiment, but the grammar is not, in my opinion, the right vehicle to convey such guidelines. There's precedent and a strong convention in many programming languages that braced blocks can be positioned in a rather free-form manner relative to other symbols. I think we should respect it. Otherwise, it's going to turn out that our syntax is actually really quite whitespace-significant outside patterns, too.

@eemeli All your unresolved comments are related to the whitespace requirement around {...}, both when used to wrap expressions and when used to wrap patterns. Are you willing to relax your opinion on this?

After some consideration, I think my only remaining concern is minification. I agree that there's some value in being lenient during parsing.

For existing web formats such as CSS, JSON & JS, when they're transmitted over the wire, it is common for any extra spaces, comments and such to be stripped out, which leads to a formulation that's sufficiently terse to need tooling before it's understandable by humans.

If we make spaces around {...} optional, we would end up with messages being transmitted in such form as well:

let $f={(foo)}match{$f}when 1{yes}when *{no}

On the other hand, if we require the spaces, the minimum size of this message would grow by six characters, but it would be much more human-readable:

let $f={(foo)}
match {$f}
when 1 {yes}
when * {no}

I would be interested to hear if anyone else has thoughts on this aspect, which I'm not aware of us explicitly discussing before. If you think that this is not of much concern, then I'd be fine relaxing my stance.

I would be interested to hear if anyone else has thoughts on this aspect, which I'm not aware of us explicitly discussing before.

It's fair to expect that people will want to attempt minification, although personally I wouldn't recommend it, mostly for practical reasons. Our syntax is already quite minimal and most of the contents of a message is the translation itself—which must not be minified. I can perhaps see some opportunity in removing leading whitespace from before when clauses, if the original formatting indents them. But otherwise, the benefits of minification are going to be minuscule.

Compressing message content (over the wire or at rest) any time size matters using GZIP or other standard mechanisms will be several orders of magnitude more effective than any possible minification, and also completely unaffected by any attempts to minify before compression.

[...] I can perhaps see some opportunity in removing leading whitespace from before when clauses, if the original formatting indents them. But otherwise, the benefits of minification are going to be minuscule.

Actually, the benefits of minifying message resources can be significant, when considering a well-commented file as a starting point. All of the contextual information required for translation is unnecessary at runtime, and can easily make up a quarter or more of the total size. If/when used for web content, MF2 resources will be minified.

The application of an intelligent minifier is going to rely on a parser that understands the syntax it's working with, and it will apply all possible savings, trimming whitespace wherever it can even if the difference between match {...} and match{...} is, as I would agree with you, minuscule.

To see what I mean, take a look at the static nominally human-readable text-based assets that are loaded alongside the HTML of this very page, and observe that they are all minified to the furtheset extent possible.

Given this, my point here then is that making the whitespaces around {...} that we're talking about optional will lead to minified MF2 content being just as unreadable as minified CSS, whereas making them required will make the minified output much more readable.

As a data point regarding minification, the total compressed size of all 280 FTL files currently in the Firefox repo is 274kB when raw, but 201kB minified; that's a saving of about 27%. I would expect minification of an MF2 resource format to provide similar file size savings for most users.

I would guess most of the savings can be attributed to the removal of comments, the indentation of attributes and the indentation of nested selectors? None of which exist in MessageFormat 2.

Taking a step back: are you advocating that minification is unavoidable and that we should attempt to preserve the readability of minified messages at the expense of the parser’s leniency?

Minification as a process is not geared towards human legibility and it doesn't bother me that JS code (or MF patterns) aren't as legible after passing through such as process. It does, however, provide the "opposite extreme" to blowing up whitespace and might serve as a useful reminder of what "valid" looks like.

Note that translation systems might produce minified patterns by default, since they have no reason to prettify patterns by inserting extraneous whitespace. So we should be reasonably happy with minified results, as lots of processors will likely fold up whitespace.

As such, I think our current syntax holds up pretty well, based on @eemeli's example: let $f={(foo)}match{$f}when 1{yes}when *{no} While that's not optimal, it can be visually parsed.

I would be interested to hear if anyone else has thoughts on this aspect, which I'm not aware of us explicitly discussing before. If you think that this is not of much concern, then I'd be fine relaxing my stance.

I also think it would be preferable to require whitespace around {...}, even if that is stricter. I think it increases the readability of the selector+variant portion because the whole thing becomes consistently space-separated.

We haven't talked about whitespace specifically, but here are my high level understandings of how we think about the syntax:

1. It should be able to represent the data model 1:1
2. It should be human-friendly

Explaining the above, starting with the 2nd point (human-friendly representation), I think the argument for eschewing delimiters (#253, #255) in favor of keywords (#287) was that it would be more human-friendly. The space savings and regularity of delimiters were not the biggest criteria for those arguments in favor of keywords.

Regarding the first point, it should be obvious. Ever since we started talking about the syntax in earnest (#178), we've wanted to have a syntax that represents anything that the data model can specify. And even though "human-friendly" can be a squishy thing to measure (ex: I think delimiters are more important for readability than keywords), I'm okay because I know there's always a 1:1 correspondence to any other representation/API I would find.

So we already have precedent for when readability in service of being human-friendly wins over saving a few characters. I think the minification arguments don't move me much because, at this point, the unresolved comments all relate to whitespace around {...}, which seems too relatively infrequent. I also trust / agree with @alerque 's sentiment that if we really care about space savings, then we would be better off starting with a compression like GZIP.

@stasm's point about parser leniency (should this be required vs. optional?) is expounded upon more over in the issue at #340 (comment), so I'll respond there.

@eemeli How much of that difference is the removal of optional and inconsequential (but potentially hefty) blobs like comments an how much is reducing the syntax niceties like whitespace to a minimum?

@stasm:
I would guess most of the savings can be attributed to the removal of comments, the indentation of attributes and the indentation of nested selectors? None of which exist in MessageFormat 2.

Also in answer to @alerque: The vast majority (probably something like 95%) of the savings come from dropping comments.

Taking a step back: are you advocating that minification is unavoidable and that we should attempt to preserve the readability of minified messages at the expense of the parser’s leniency?

I would like us to be explicit about the choice we're making. We're building a new format for encoding human messages that we've put some work into making human-readable. The ecosystem around us is one that now has years of experience applying AST transforms on source code for various purposes, so the complexity and cost of applying e.g. minification to MF2 is marginal. Therefore, we should presume that it will be used by at least some large fraction of MF2 emitters that presume that their output will primarily be consumed by machines rather than humans.

So while it is entirely valid for us to make the call that whitespace being optional results in a more lenient parser and that's desirable, I want our choice on this to be explicit rather than implicit.

At the February 27 teleconference we agreed to move ahead with this PR. To summarize the current agreement, there have been three major threads of discussion above:

1. whether to require whitespace around {...}, i.e. whether match{...} should be allowed,
2. whether to require whitespace between variant keys, i.e. whether when*** and when foo* should be allowed,
3. whether to require whitespace between option pairs, i.e. whether {:func opt=(x)opt=y} should be allowed.

This PR implements the following answers:

1. no, whitespace around {...} is optional,
2. yes, whitespace between variant keys is required,
3. yes, whitespace between option pairs is required.

During the meeting we also discussed possibly further relaxing the whitespace requirements related to (2) and (3) above. I'll file a new PR with suggested changes to the BNF, and we will continue the discussion there.

I believe this will almost immediately be overwritten by the ABNF version??

Yes. #347 will follow today or tomorrow.