Find deterministic sizing rules for free-form documents

• Upcoming
• Tentative
• Breakout Sessions

Historically, the viewport of html documents has always been determined by the browsers frame, being the browser window, browser tab, or browser popup size. The author of the html document can then base their own styling and dimensions based on this size with units like vw and vh which in these situations are deterministic and non-ambiguous.

With the introduction of web extensions, a new type of situation is born in which the author of the html document can, with certain restraints and many issues (which you can read about below) determine and change the size of the viewport by changing the height/width of the html/body elements. Examples are the extension popup and the options page if defined with options_ui.open_in_tab=false.

In an ideal world the document would communicate (in any form, declarative in css for example) its preferred min/ideal/max height/width if in auto size. In which the ideal height/width could also mean "match" the browsers ideal sizing if it sits in between the min/max range. This preference is then incorporated by the browser and either fully or partially respected to render the auto-sized content.

There is some prior art in the CSSWG which discusses the auto-sizing of iframe elements on their parent document. See:
https://github.com/w3c/csswg-drafts/issues/1771 and https://github.com/domenic/cooperatively-sized-iframes
and in the WECG:
https://github.com/w3c/webextensions/issues/692 and https://github.com/w3c/webextensions/issues/436

Some of the techniques currently in use for the auto sizing and some of the proposals to accompany them can be reused/shared for auto-sizing of iframes.

With iframes, security is a concern so the auto-sizing can not be opt-in by default for both host and iframe. A potential way to address this would be adding a "autosize" keyword to the <meta name="viewport"> and an autosize attribute on the iframe.

Agenda

Chairs:
Carlos Jeurissen

Description:
Historically, the viewport of html documents has always been determined by the browsers frame, being the browser window, browser tab, or browser popup size. The author of the html document can then base their own styling and dimensions based on this size with units like vw and vh which in these situations are deterministic and non-ambiguous.

With the introduction of web extensions, a new type of situation is born in which the author of the html document can, with certain restraints and many issues (which you can read about below) determine and change the size of the viewport by changing the height/width of the html/body elements. Examples are the extension popup and the options page if defined with options_ui.open_in_tab=false.

In an ideal world the document would communicate (in any form, declarative in css for example) its preferred min/ideal/max height/width if in auto size. In which the ideal height/width could also mean "match" the browsers ideal sizing if it sits in between the min/max range. This preference is then incorporated by the browser and either fully or partially respected to render the auto-sized content.

There is some prior art in the CSSWG which discusses the auto-sizing of iframe elements on their parent document. See:
https://github.com/w3c/csswg-drafts/issues/1771 and https://github.com/domenic/cooperatively-sized-iframes
and in the WECG:
https://github.com/w3c/webextensions/issues/692 and https://github.com/w3c/webextensions/issues/436

Some of the techniques currently in use for the auto sizing and some of the proposals to accompany them can be reused/shared for auto-sizing of iframes.

With iframes, security is a concern so the auto-sizing can not be opt-in by default for both host and iframe. A potential way to address this would be adding a "autosize" keyword to the <meta name="viewport"> and an autosize attribute on the iframe.

Goal(s):
Brainstorm about potential solutions and reduce the scope of solutions to determine next steps.

Materials:

• Session proposal on GitHub

Joining Instructions

Instructions are restricted to W3C users . You need to log in to see them.

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

• Download as ics