Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reference to the initial containing block definition should be improved #2292

Closed
iherman opened this issue May 14, 2022 · 2 comments · Fixed by #2341
Closed

Reference to the initial containing block definition should be improved #2292

iherman opened this issue May 14, 2022 · 2 comments · Fixed by #2341
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Topic-ContentDocs The issue affects EPUB content documents

Comments

@iherman
Copy link
Member

iherman commented May 14, 2022

(I realized this while preparing #2291).

The section on ICB defines the viewport meta tag for FXL referring simply to the CSS Device Adaptation Module Level 1. However, I did not find, in that document, a clear definition for that meta tag. The only one I found was the (informal) §9 which says:

This section describes a mapping from the content attribute of the viewport element, first implemented by Apple in the iPhone Safari browser, to the descriptors of the @viewport rule described in this specification.

In order to match the Safari implementation, the following parsing algorithm and translation rules rely on the UA stylesheet below.

This can hardly be considered as a normative reference. Furthermore, that section lists a number of properties that we do not talk about, not clear whether they are considered as o.k. for FXL (but handling those extras is a significant portion of the section).

I wonder whether we should not simply define the meta tag ourselves (it is fairly simple after all).

@mattgarrish @wareid @dauwhe

@iherman iherman added the Topic-ContentDocs The issue affects EPUB content documents label May 14, 2022
@mattgarrish
Copy link
Member

mattgarrish commented May 18, 2022

Ya, we've struggled with the definition since introducing it. We used to reference the Apple documentation, but that's an equally poor choice and we had a number of complaints about using it.

I don't like the idea of creating a competing definition because if we define it ourselves don't we effectively have to reproduce all of the requirements of the Apple definition and possibly a parsing algorithm like in the CSS spec? But I also don't know what better alternative there is.

And there isn't a restriction against using other properties in the declaration. We used to have this statement: "In this version of this specification, only the width and height expressions must be recognized by Reading Systems." I believe this was dropped because it's a bit redundant to say only height and width must be recognized when we also require they be used. We could be clearer that other properties are allowed, though.

What I wonder about looking at the definition is whether 'device-height' and 'device-width' are considered acceptable values for the height and width declarations? I thought we expected a numeric value.

@wareid wareid added the Agenda+ Issues that should be discussed during the next working group call. label Jun 22, 2022
@iherman
Copy link
Member Author

iherman commented Jun 24, 2022

The issue was discussed in a meeting on 2022-06-23

List of resolutions:

  • Resolution No. 2: Define the meta viewport property with only the width and height attributes as a restriction on the CSS definition, close issue 2292.
View the transcript

2. Reference to Initial Containing Block definition should be improved.

See github issue epub-specs#2292.

Dave Cramer: we have a viewport meta tag for FXL. It has an informal definition in a CSS module, but Ivan feels like that isn't a good enough reference.
… he suggests that we define it ourselves. But from experience, defining things related to layout is really difficult.

Wendy Reid: i'm in favor of defining it only because RS already use this tag in a very very specific way.
… we can even say that our definition is for RS only, and not to expect the same behaviour elsewhere.
… and the way we use it isn't documented normatively anywhere else in our spec.

Dave Cramer: do people ever use anything else in this element other than dimensions? No other units?.

Brady Duga: I think somewhere someone has probably put 'px' after the number value.

Dave Cramer: the amount of variation out there is a concern.

Wendy Reid: I've almost always seen numeric values, not ems, not device-height.

Brady Duga: i'm almost certain we've had bugs related to this, but I don't recall what weird thing people have tried.

Wendy Reid: I'e seen bugs where people try to make different content documents different sizes.

Brady Duga: there's a test for device-height.

Wendy Reid: we could create a bunch of different test FXLs that try to use different units in this element. Easy enough to test.

Matt Garrish: when we define this with the Apple documentation it required pixels. It was only when we switched to referencing CSS that we began to open the door to these other sorts of values.
… not sure we did that intentionally.
… we could always define it strictly and see what feedback we get.

Dave Cramer: limit it to just 'width' and 'height'.
… trying to imagine if various types of relative units make sense in there.
… do we know how RS would treat device-height and device-width?.

Wendy Reid: whatever viewport the RS happens to be in, maybe?
… i feel like there was guidance about this in our best practices documentation.
… what did it say?

Dave Cramer: no, we don't say anything specific about that other than that it must be included, and all examples given are in pixel values.
… would be interested in making a FXL with 'device-height' and 'device-width' but run it in a desktop RS.

Brady Duga: Play parses the value and just takes the beginning number value regardless of what the unit is. Unless it is device-height or device-width. We pass those back.

Dave Cramer: propose that we define viewport meta, but only allow width and height properties as a restricted version of the CSS definition, but that we don't place further restriction on what values may be used in 'width' and 'height'.

Brady Duga: what about things that have initial scale on the viewport?

Wendy Reid: not part of our definition. Other properties on viewport meta are undefined.

Proposed resolution: Define the meta viewport property with only the width and height attributes as a restriction on the CSS definition, close issue 2292. (Wendy Reid)

Wendy Reid: +1.

Matthew Chan: +1.

Shinya Takami (高見真也): +1.

Dave Cramer: +1duga.

Matt Garrish: +1.

Toshiaki Koike: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Murata Makoto: +1.

Resolution #2: Define the meta viewport property with only the width and height attributes as a restriction on the CSS definition, close issue 2292.

@iherman iherman removed the Agenda+ Issues that should be discussed during the next working group call. label Jun 24, 2022
@mattgarrish mattgarrish added the EPUB33 Issues addressed in the EPUB 3.3 revision label Jul 20, 2022
@mattgarrish mattgarrish added the Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation label Sep 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-EPUB3 The issue affects the core EPUB 3.3 Recommendation Topic-ContentDocs The issue affects EPUB content documents
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants