First, sorry about missing the discussion in #2292, #2341, and #2350 last summer. It went totally under my radar! 😅

A couple (late) comments:

• there has been recent developments around the concept of viewport:
  • viewport is one of the topics of the interop 2022 project
  • the CSS WG resolved a while ago to retire the CSS Device Adaptation spec, remove the definition of @viewport, and move the viewport meta tag definition to a new spec. A CSS Viewport draft was just created.
• the new EBNF syntax of the viewport meta tag in EPUB 3.3 is somewhat restrictive when compared to the parsing algorithm defined in CSS Viewport (formerly CSS Device Adaptation).
  • the parsing algorithm in css-viewport does not produce errors, but always returns a (possibly empty) se tof name/value pairs.
  • in contrast, our definition defines a static syntax, but does not completely tell how RS should deal with an invalid value (except for number-prefixed height/width values).
  • for example, for a viewport value of ",invalid,,height=200,width=,width=100" the algorithm returns the name/value pair list ("height","200"),("width","100"), when our spec just says the value is invalid.
  • that said, the CSS algorithm itself has room for improvement: it could define parsing errors, error handling, and how to deal with duplicate properties. (also, it would be worth being rewritten based on Infra).

Some concerns:

• is it ok to reference css-device-adapt (even informatively) when we know the spec is doomed?
  At least, I would rephrase the following:

  The syntax of this grammar is also influenced by the processing model for transforming viewport meta tags to @viewport CSS rules, as defined in css-device-adapt.

  to something along the lines of:

  The syntax of this grammar is also influenced by the parsing algorithm for the viewport meta element, as defined in css-device-adapt.

  (so that we no longer reference the for-now-defunct @viewport at-rule.

• I have a (slightly) nagging feeling with having our own normative definition of the viewport meta element in EPUB:

  • what if this definition conflicts with whatever will (hopefully) be defined in CSS Viewport? It already kinda does. Although our definition seems to be a subset: something valid to the EPUB definition will be parsed as expected by the CSS algorithm, but not all values that are parsed into something by the CSS algorithm are conforming to our definition.
  • how confident are we that this definition matches the reality of implementations? (the existing EPUB tests not extensively evaluate the syntax variations)
  • can our syntax be informative only, somehow?
  • these types of structured values are better defined algorithmically (in my opinion), so that the algorithm can both define syntax (i.e. parsing errors) and error handling (i.e. recoverable errors that still produce a returned value).