This is just after a quick glance, will do a more thorough review when I am back from vacations...

If I was a first time reader of this spec I would be really messed upon why on earth are these guys bothering with the introduction of those terms in the section that seem to be unnecessary (e.g., initial-scale). In this respect, I preferred the extended EBNF syntax that you proposed in another PR that left open the other possible terms (and we can put a reference to the apple spec). That PR also had a reference to history as for why we bother in the first place (because we try to be backward compatible, that is). I also think that we should try to be a bit more forthcoming in saying that authors should not use those other property values and reading systems should ignore them.

(I like the idea of moving the formal grammar to the appendix, b.t.w.)

I preferred the extended EBNF syntax that you proposed in another PR that left open the other possible terms

Ya, I was thinking this morning that we don't want to validate for names, but that's probably where it leaves us if we're too specific. I've changed the definition to:

name = "height" | "width" | ? character data ? ;

It just feels like we should list the two properties that we're expecting to be set. That's what initially led me to list all the ones from the apple def, but I think the above is a good compromise.

I also think that we should try to be a bit more forthcoming in saying that authors should not use those other property values and reading systems should ignore them.

Other than discouraging their use we fall into the trap of potentially invalidating existing content.

But if reading systems have to ignore everything but height and width in fxl documents, then does it become required that they completely ignore viewport meta declarations in reflowable? It would be weird to disallow it in one rendering and not in the other.

Another question is what is a reading system supposed to do if there is more than one viewport declaration? If it uses the first, what if it's invalid? It's not like viewBox where you can only have one declaration.

The key changes in the last commit are:

• the ebnf definition is more generic than I mentioned in my last comment. It's just "? character data ?" now, as we define the height and width requirements in the fxl section. The default definition can be as simple as possible.
• it adds a clarification that height and width are required properties as changing the definition meant we only had requirements on the values
• it adds a requirement for RS to strip non-numeric character data and use resulting number as the dimension.
• it adds a requirement to use first viewport declaration if more than one (if this ends up being invalid, then the result would be that device-width and device-height are used as the defaults)
• it adds a new section to ignore viewport meta declarations in both reflow and fxl (except for getting icb dimensions)

The latter has me the most concerned, as I'm not sure what effect setting things like initial-scale has in an epub. It's necessary for mobile, so if the document gets read in a mobile RS is it good practice to set these properties?

Do we need to tell reading systems anything about other properties when they aren't in scope of the ICB calculation?

Just note for archival purposes: this PR grew out of the extensive discussions in #2341; it was simpler to put everything into a new PR rather than carry on over there. But the technical discussions in #2341 are certainly "part" of this PR, too.