• I have not found any explicit statement in the CSS specs whereby the value of "500" defaults to "500px".

The CSS spec is a mapping from the Apple definition to the @viewport property; it's not actually a definition of the viewport meta tag itself. (That's one of the problems of referring to it even in the future.)

The Apple definition only allows a limited range of numeric values that are defined as being in pixels plus the device-width and device-height keywords, so I would take that as the formal definition we should use, and we should also account for the range restriction.

If you look at the mapping for these properties in the CSS spec, it also only accounts for these values.

• the missing dimension is set to the device's (or browser window's) own size.

The fourth rule in the parsing section states:

Other keywords and unknown values translate to 1px

Is a missing value an unknown value?

There is a condition where you get an auto width defined further down, but that applies only if you parse the initial-zoom to something other than auto, but we don't account for that property.

@mattgarrish I am not sure about all that you are saying.

• The meeting minutes seem to indicate that we should allow for, e.g., explicit px unit string. I realize this is not what Apple does, they seem to use unitless values only. But in my reading of the minutes we want to go beyond that. I would be happy to restrict our definition to simple numbers (actually, that was the first version of may changes, but then I read the minutes again...)
• In case we do want to allow unit values, do you mean we should not rely on the CSS <length> type? Because if we do then the default pixel value is still a question, because that data type seems to be restrictive in this respect.

I must admit that the CSS Device Adaptation module was unknown to me (I am unable to keep track of all the CSS specs)☹️

Personally, I would be happy to simplify the definition to rely on simply numbers...

• The meeting minutes seem to indicate that we should allow for, e.g., explicit px unit string.

The assumption on the call last night (but others can correct me if I'm wrong here) was that other value declarations are allowed, but rereading the relevant documents this morning I can't find any evidence that's true. I don't think we should be creating a new definition of the viewport meta tag that allows any type of declaration, or that adds units (even for pixels).

The Apple definition is the originator of this property, as the CSS spec mentions, and is what we based the original FXL requirement on. The CSS spec is trying to replace the meta tag with a CSS property, but even if that happens it'd be too late to change how we process FXLs.

@bduga also mentioned last night that if someone tries to declare a unit they just strip it and use whatever numeric value was input as pixels.

Or put another way, we need to be careful that our definition reproduces the viewport meta tag syntax, not the @viewport property syntax. The latter allows any CSS values and units, not the former.

I am happy to simplify the text and simple say that the height and width values must be positive numbers, that mean pixels, and stop there. But I would prefer a nod from @dauwhe, @wareid, or @bduga to be sure that this is what the WG resolution should lead to.

I think simplification helps here. They must be positive numbers, we were reluctant to say they must be pixels because there is potential for other values there and we didn't want to invalidate current content. I think the language around defaulting to pixels in the absence of any other value is ok.

I think we should require a positive number only, no units or other text, and the implied unit is pixels. That, at least, is the Play behavior. I don't think CSS units in non-style attributes are common, and there is certainly no specification for this element that allows them here. I did mention that Play will just read the leading number, so "145", "145px", and "145em" will all be allowed and treated as 145 pixels. But that shouldn't go in the spec, that is just us trying to deal with silly things we get in practice as best we can.

I have updated the viewport definition. It now says:

The attribute value MUST be either width=XX,height=YY or
height=YY,width=XX, where XX and YY are
positive numbers, and express the horizontal, respectively vertical, dimensions
of the initial containing block in pixels.

I have also added a paragraph to the reading system spec:

If the viewport meta does not contain a width or a height value,
the reading system SHOULD use the width, respectively the height, of the device.

I think we should not mention the missing value in the core spec (let that be an error to be found by ebupcheck), but something has to be said on the RS as an error behaviour...

The attribute value MUST be either width=XX,height=YY or
height=YY,width=XX

I thought we were allowing for other values but not defining them ourselves? While I expect height/width will normally be paired, do we want to require it and allow other values? Will that confuse people?

Doesn't this definition make whitespace illegal, too? That's likely to invalidate existing content. We could say in the RS spec to remove all whitespace from the meta tag's value before processing rather than put it on authors.

Also, aren't we were allowing the device-height and device-width keywords in addition to a numeric value?

The Apple definition also has a restriction similar to what @bduga has mentioned:

For numeric properties, if the value contains a nonnumeric character but starts with a number, then the number prefix is used as the value. For example, 1.0x is equivalent to 1.0 and 123x456 is equivalent to 123. If the parameter doesn’t begin with a number, the value is 0.

Should we formalize this in our definition?

The attribute value MUST be either width=XX,height=YY or
height=YY,width=XX

I thought we were allowing for other values but not defining them ourselves? While I expect height/width will normally be paired, do we want to require it and allow other values? Will that confuse people?

Personally, unless there is a deployment for more, I would keep it simple. These are the possible values and only these.

Doesn't this definition make whitespace illegal, too? That's likely to invalidate existing content.

Yep, we should probably say that any number of spaces (or whitespaces) are allowed before and after the "," character.

We could say in the RS spec to remove all whitespace from the meta tag's value before processing rather than put it on authors.

Well, we should make clear the space to allow the content to be accepted by epubcheck.

Also, aren't we were allowing the device-height and device-width keywords in addition to a numeric value?

No idea, to be honest. I mean: this is the first time I see these, I must admit, and what I do not know if there are fxl documents using these. If there are, we must allow for it (sigh. The definition becomes a bit more complicated...)

The Apple definition also has a restriction similar to what @bduga has mentioned:

For numeric properties, if the value contains a nonnumeric character but starts with a number, then the number prefix is used as the value. For example, 1.0x is equivalent to 1.0 and 123x456 is equivalent to 123. If the parameter doesn’t begin with a number, the value is 0.

I would keep it simple: the content document should allow a positive number (with a possible device-height/width values), period.

We can add, if we want, that type of sentence for the RS spec as a possible strategy for handling illegal values. But only as a SHOULD; RS may choose to simply ignore the values altogether.

My 2 cents...

Should we formalize this in our definition?

Personally, unless there is a deployment for more, I would keep it simple. These are the possible values and only these.

The spec has allowed whatever is valid per the Apple definition for going on 10 years now, so can you be sure this new definition won't invalidate existing content?

Technically, it hasn't even been required to use a comma to separate the values, since that's valid per the definition, too.

Personally, unless there is a deployment for more, I would keep it simple. These are the possible values and only these.

The spec has allowed whatever is valid per the Apple definition for going on 10 years now, so can you be sure this new definition won't invalidate existing content?

Sigh. Technically, this is true. Although I am almost sure that implementers did copy-paste starting with the examples in the spec, we cannot be sure of that. I have not enough experience with FXL documents to decide on that...

Technically, it hasn't even been required to use a comma to separate the values, since that's valid per the definition, too.

Sigh...

Trying to summarize the changes that may cover current practice and may be enough:

• accept white space around the ',' and, I presume, around the '=' signs
• accept device-* values as alternative to numerical values
• possibly drop the ',' character

This could cover the formal specification of the format.

We can then add a set of advices to the RS what to do with missing or erroneous values, and numbers with some extra characters. To avoid epubcheck to throw out these types of values, we may also have to add some extra text whereby these types of extras MAY be used, but their usage is deprecated.

Would that work?

B.t.w., looking at https://www.w3.org/TR/css-device-adapt-1/#translate-meta-to-at-viewport it says:

The recognized separator between property/value pairs is comma for the Safari implementation. Some implementations have supported both commas and semicolons. Because of that, existing content use semicolons instead of commas. Authors should be using comma in order to ensure content works as expected in all UAs, but implementors may add support for both to ensure interoperability for existing content.

Ie, I do not think a space is allowed as a separator; a semicolumn is.

What about simplifying things, roughly, saying that

• our specification defines, normatively and for the purposes of FXL only, a restricted version of what is described in the CSS DAM text (along the lines of what was listed in Added the defintion for fxl viewports in xhtml #2341 (comment) except for the usage of ';' or ',');
• we say that authors MAY use the full syntax of what is in the CSS DAM text but any syntax beyond what is defined in the previous section is deprecated;
• RS-s SHOULD make their best to map, reasonably, all the extra quirks in the CSS DAM text to something they can interpret, but without defining what that is.

Ie, I do not think a space is allowed as a separator; a semicolumn is.

Ya, but the apple documentation says:

• Do not use a semicolon as a delimiter.
• A space may work as a delimiter, but a comma is preferred.

This is the nightmare of trying to make this our own!

• a restricted version of what is described in the CSS DAM text

But, again, my problem with the CSS module is that it defines a translation, not a syntax. You can't read that document and get a syntax from it, only how to process what you might encounter in the meta tag into an @Viewport rule.

It's more like the reading system side of the equation.

I'd go dead simple in the authoring definition:

• define the expected height and width values (numeric + keywords)
• require either a comma or space to separate
• note the declaration may contain other properties for compatibility purposes

Whatever work there then is in splitting apart the properties shouldn't be that hard to implement on the reading system side, since it sounds like browsers already have to account for these variations. We then only need to say what to do when values are invalid (negative, have a unit) or not specified, and how to handle the device-* keywords.

I have made an update that, hopefully, reflects a consensus.

• I have replaced the prose for the viewport content definition by an EBNF table. The syntax should take into account:
  • Whitespaces around the dimension assignment (i.e., '=') sign and between the width and height definitions
  • The separator between the height and width values are currently set to comma, semi-column, or space. It is easy to modify this; I would like to hear from @bduga or @danielweck whether their respective systems implement all three or whether we should restrict it to, say, semi-column.
  • I have added the device-width and device-height alternatives to the numerical dimension values.
• I have added a note that refers to the CSS device adaptation document as a syntax for a more complex meta element, and makes it clear that anything that is not defined in the EBNF is deprecated. I guess this statement makes it possible for epubcheck to run without creating problems for existing contents (@rdeltour, is this the case?)
• I have slightly extended the text in the reading system spec, saying that invalid dimension values should also be considered as device width or height, and adding also an extra MAY statement that RS-s may use some best effort to make sense when deprecated syntax is used. This should cover, say, the RS that tries to make sense of 123px.

Hopefully that covers it...

While I am at it, I have also added a note on the SVG portion of the reading system side, reflecting to #2270, noting that a reading system should follow the SVG specification that involves the behaviour of viewbox and preserveAspectRatio. This is all part of the SVG spec, and these changes are only a note, but the text itself was fairly imbalanced between XHTML and SVG in this respect (as @dlazin realized).

Play supports comma and space as separators, but not semicolon though we could easily add it if we wanted to. An alternative to allowing all whitespace in sep would be to just define it as (";" | "," | #x20)+, or however EBNF does 1 or more. I doubt the whitespace used there is ever anything other than a space (and if it is, don't do that!). It also means silly things like height=100,,width=200 work in a reasonable way.

Play supports comma and space as separators, but not semicolon though we could easily add it if we wanted to.

I am happy removing that if this is what we decide

An alternative to allowing all whitespace in sep would be to just define it as (";" | "," | #x20)+, or however EBNF does 1 or more. I doubt the whitespace used there is ever anything other than a space (and if it is, don't do that!).

Actually, I can imagine somebody doing, for the sake of code readability, something like

<meta 
   content = "width = 300
              height = 600"
>

It also means silly things like height=100,,width=200 work in a reasonable way.

This is not legal in the current EBNF, right? Honestly, it is so ugly, that I would prefer epubcheck yelling at me if I did that...

An alternative to allowing all whitespace in sep would be to just define it as (";" | "," | #x20)+, or however EBNF does 1 or more. I doubt the whitespace used there is ever anything other than a space (and if it is, don't do that!).

Actually, I can imagine somebody doing, for the sake of code readability, something like

<meta 
   content = "width = 300
              height = 600"
>

Does that matter? Doesn't xml attribute normalization convert whitespace to spaces? I think even cdata will have them converted, though not collapsed.

It also means silly things like height=100,,width=200 work in a reasonable way.

This is not legal in the current EBNF, right? Honestly, it is so ugly, that I would prefer epubcheck yelling at me if I did that...

Well, if we allow multiple spaces as a separator, I don't see why multiple commas are any worse. It's just a little odd for the matching, I think EBNF subrules are greedy so doesn't width=100 height=100 match { whitespace } ? In which case there is no separator. It's just weird to put repetitions of a character around a character. Though I have to admit I am not an expert in EBNF.

Though I have to admit I am not an expert in EBNF.

Neither am I. I guess we have to rely on @mattgarrish for this...

You may be right about the XML normalization point, though, ie, it may be enough to set the sep, without { whitespace } and make a statement in the text that the attribute normalization applies (is there a suitable pointer to this?)

You may be right about the XML normalization point, though, ie, it may be enough to set the sep, without { whitespace } and make a statement in the fact that the attribute normalization applies (is there a suitable pointer to this?)

https://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize

Though I think that will just convert all the non-space characters to spaces. Basically I don't think we need to worry about whitespace generically, just space characters.

Thanks @bduga. I have updated the EBNF, it may look a bit more readable. It now explicitly operate on the normalized attribute value, so one should only look at spaces. I have not changed the separator value alternatives.

@mattgarrish I wonder whether we should do the same with the EPNF in D.1.4, ie, remove the whitespace reference and definition and use space only...

I wonder whether we should do the same with the EPNF in D.1.4, ie, remove the whitespace reference and definition and use space only...

I was hoping I wouldn't have to think about this one at all! (head's still pounding from the last week of headaches... ☹️)

I'll read over the changes in more detail on the weekend, but would be helpful if @danielweck can have a look, too. If memory serves, he wrote the original EBNFs in the spec.

I'm a bit concerned that with EBNF we're trying to be too precise about the value. I thought we were allowing but not defining other properties that might appear in the tag, for example? The EBNF will make these an error.

Even something like width=#,,height=# is invalid as you can't have an empty definition between the properties. If we wanted to allow this without accounting for other properties, the separator definition would probably have to change to a sequence:

sep = sep_char, { sep_char }
sep_char = ";" | "," | " "

This PR should be closed without further steps if and when #2350 is merged, because that one supersedes this one.