Ya, I was thinking of putting a note in saying it allows invalid properties, but didn't like saying it out loud. Reinforcing we have name/value requirements for height/width isn't a bad thing

Looking over the full section, though, I found some further inconsistencies to clean up:

• I think it's better to say right at the beginning that this syntax is only for FXL.
• I fixed a few hrefs in the ebnf that were missing hashes at the start.
• I added space around all the ebnf special characters, as sometimes we had whitespace and sometimes not.
• I took the text about whitespace handling out of a note, as it is saying normatively when to validate the syntax.
• I changed the vague reference to HTML whitespace to a specific reference to ASCII whitespace in the infra spec (since that's what HTML references).

Finally, I put the text about the required properties and values into the note that discourages other uses, plus added some text that we don't even require values for other properties. That leaves all the processing normative, rather than interspersing some text about why we have this syntax. It's not as immediate as saying why we have the syntax right after the ebnf, but feels a little clearer for reading (we also mention it's for fxl height and width in the intro, so it's plenty covered now).

Looks fine to me, and there is a clearer separation between the Syntax of the tag and the definition of what w/h are for.

One minor thing. In the meantime, I merged the PR on viewport setting, which included this:

The content attribute MUST NOT include several height, respectively width, assignments.

I presume that should still stay and github's merge magic will take care of that...

I presume that should still stay and github's merge magic will take care of that...

Ya, it's still there, but does it make sense to have that specific a restriction in the general syntax definition? If we want to make it exclusive to height and width, then shouldn't that be part of section on setting the FXL dimensions?

For now, I've tweaked the paragraph to say that all duplicate definitions are illegal and put width and height into a parenthetical.

I presume that should still stay and github's merge magic will take care of that...

Ya, it's still there, but does it make sense to have that specific a restriction in the general syntax definition? If we want to make it exclusive to height and width, then shouldn't that be part of section on setting the FXL dimensions?

For now, I've tweaked the paragraph to say that all duplicate definitions are illegal and put width and height into a parenthetical.

As we do not put any restrictions on other parts of the definitions, making any statement (even duplication) on a term other than w/h may not be appropriate. And you are right that, in this new setting, the statement should probably go to the FXL definition.

making any statement (even duplication) on a term other than w/h may not be appropriate

Right, and I woke up this morning thinking that we should also be saying something about not including duplicate definitions by having multiple viewport tags, since reading systems are supposed to ignore subsequent ones. I've moved the restriction and also added that clarification into it.

It looks good to me now. B.t.w., the RS spec already says, in the section on ICB §8.1.2. how to handle multiple viewport declarations, which is good; all loose ends are now tied.

It's a go for me.

A careful reader might wonder why the EBNF explicitly allows some invalid forms (value-less keys) while forbidding others (e.g. leading or trailing separators). But practically I don't think it will happen often with real-world content, so whatever the EBNF allows/restricts is probably ok!

Right, I don't think anyone is going to care given that the viewport meta tag has only one purpose in fixed layouts. We could add a note clarifying that the syntax is meant to be as loose as possible to ensure that (invalid) properties we don't care about don't invalidate the publication, but this is all a technical detail related to W3C process. I doubt authors will notice we even have our own syntax, let alone try to decipher the EBNF! They'll just copy the examples.