Meeting minutes
Slideset: https://
Slideset: https://
carlosj: Previously discussed autosizing of <iframe>s
… Similarities to that and web extensions sizing. Maybe can solve in a similar fashion.
… Hopefully make soe progress.
carlosj: Current extensions model, these are sized based on whatever the popup specifies.
… E.g. if specifies that it's 500x500, then that's what browser ends up using.
… Similar approach to contain-intrinsic-size: from-element
… There's a bunch of issues.
carlosj: A browser may imply a size limit, e.g. if youre HTML is taller than this limit then you get scrollbars.
carlosj: A lot of inconsistencies, even between popup and dialog
carlosj: firefox differences between options and popup
carlosj: Extension popups can be in two states in Safari. Freeform, similar to before, and fixed version in which size is determined by the browser.
carlosj: As an extension it's not very obvious how to distinction.
carlosj: So lots of hacks to try to compensate for this
carlosj: It's hard to both give clues to preferred sizing while also sizing into an explicitly sized dialog
carlosj: Browser needs to be able to decide sizing. Need ability to update. ...
carlosj: Ideally author should be able to specify min/max, and that should be overrideable by the author
carlosj: Author might want to opt into host sizing
carlosj: Sometimes extension can be moved from popup to full size
carlosj: There's a guessing game, so there's a need for different opt ins for back-compat
carlosj: for iframes it's more about security and privacy
carlosj: Browsers wait for extension popups to be displayed on load
… ideally it shouldn't have similar loading concepts, you want the popup to be directly available fully loaded when you open the popup
… but that requires base conditions, like not working until load is finished
carlosj: We also have issue of one-dimensional flexibility
… for example sidebars, might want self-determined width with a fixed height
carlosj: Because these are not specified, all browsers set fixed size for both of these
carlosj: A lot of work in CSSWG, last iteration was the contain-intrinsic-size: from-element
… not sure there's been progress since 2021
carlosj: Another way is for extensions to be able to query whether auto-sizing is applied
carlosj: Coudl expose constants as environment variables
carlosj: Or could explore using an @-rule, similar to @page
… E.g. @freeform { ... }
… That way avoids messing with HTML/body sizing
… and can declare your preferred sizes
carlosj: There are some issues around flickering, could address similar to <meta viewport>
carlosj: Can we explore the best ways to solve this?
… are these similar to iframe sizing? or are they separate issues?
… could webextensions be a testing ground for these questions before exposing to iframes?
carlosj: Questions / input?
emilio: The obvious thing that would be consistent with e.g. picture-in-picture would be a display-mode query
… that would allow you to check whether you're in a popup
emilio: One issue with the auto-sizing, and the requestedwidth/height attributes, is that you could end up with something cyclic
… so auto-sizing an iframe is pretty hard
emilio: the way we implement this in Firefox is that we do an extra layout pass with an unconstrained width and height, and that is pretty expensive, and you can't do it all the time
… possible to flip an MQ but it's extra expensive then
… Having a separate display mode is low-risk, and solves a lot of the use cases here.
… Seems non-controversial, maybe we should just do it and get the CSSWG to resolve on it.
… Beyond that, might be useful to know how the actual implementations works. Gecko's approach is not amazing, but it works.
… Web exensions case should be standardized in some way.
… Would be good to have a list of what each browser does
… and come up with an easy-to-understand rule.
emilio: A lot of these extensions change their size dynamically also
… so need to inform the browser somehow that it needs to resize.
… e.g. Gecko uses ResizeObserver
… but can create cyclic issues
emilio: So display-mode seems uncontroversial.
emilio: ideally standardize how we do intrinsic sizing
emilio: But don't wait for iframe auto-sizing, because that's hard.
adekker: We've struggled with this, when implementing popup stuff as well, so knowing a standard way of working would be great.
… Not having to second-guess what's happening.
emilio: If it's useful, FF internal dialogs do check computed min-width of the document element to see if it's non-auto, and same for the height.
… (this is for internal popups, not extensions)
… If the popup wants to set an explicit size, they use a DOM attribute or that.
… There was also another special case for intrinsic sizing in the horizontal axis, inline axis.
… iframe auto-sizing that uses requestedwidth/requestedheight uses something similar to this with extra constraints
fantasai: MQ wouldn't solve the loading issue
carlosj: display-mode would solve this one
… doesn't solve the double scrollbar case
… maybe could resolve by passing as environment variables
emilio: Need to communicate your preferred width outside of style
… that way you can use style as intended, and use viewport media queries to react to your current popup size
… because the constraints are exposed as the viewport
… so that's the issue
emilio: Gecko used to have an API window.sizeToContent which was intended to trigger this mechanism programmatically
Rob: For example in Firefox or Chrome, extension popu and ? paes resizes. You start from web, see if it fits, and if not you resize it, and sometimes this runs off and keeps growing
… would that be in scope for fixing?
carlosj: Ideally yes
… In this case, for FF options, the maximum height is infinite
emilio: We have a max height as well
… we constrain the popups
carlosj: But the options case
emilio: oh right
emilio: Using width: fit-content and height: fit-content might be an interesting idea
… because height: fit-content on a block is basically auto but it might be a good hint
emilio: Would be good to know what other browsers do
… The kind of measurements we can take, I can tell you our contraints, but don't know about other browsers
emilio: This solves our internal use cases
… For max-width/height, you can make things only apply on popups
… html { max-height: 500px; } will do the right hting
carlosj: Browser might have ideal size, by only specifying max and min you could potentially do that.
oriol: I was wondering to address the circularities
… if it would be possible in this popup display mode to ensure that the intrinsic contributions would not depend on the viewport size
… For example this means that viewport units don't work
… Media queries could be indefinite
… We would need to address these
… But if we could guarantee it, then we could size the viewport to the intrinsic contribution
… And then once we have this viewport size, percentages could resolve normally against this size
… Just like we do in a web-page, if you have a percentage inside an auto-sized container
oriol: Of course disabling all these features... not sure if it's ok
… maybe some people want to use them
… but that's an idea
emilio: Main issue with that is, even if you do it just for the particular measurement, you need to know when to re-run that measurement
… and that's expensive as well
… Currently we have a mutation observer, and we update it when the DOM changes
… If you want to do it for iframes, then it becomes a lot less realistic
… Maybe the frame shoudl be able to say, I want this measurement done, similar to previous sizeToContent API
… but conditionally disabling ...
… Are you proposing to disable only during meausrement or generally?
oriol: Generally.
… Media queries affect the styles that we're using
… This is taken into account when you are computing the intrinsic contributions
… But you're saying it's complex to know when to update.
… Not that different from, in a normal, an element size would depend on intrisnic contribution of its contents
… and you update when the contents change
emilio: This involves coordinating multiple processes, so it's more expensive
… but sure we can detect when intrinsic size of an element may have changed in layout
… but I'm pretty sure we don't want to re-do this measurement every time
… You change the text of a button, suddenly need to run this measureent
… Doing it every frame would not be reasonable.
oriol: Having multiple processes ...
… In general no different from eleent with fit-content, and change the contents. Possibly need to update the ancestors.
emilio: ...
emilio: Probably possible but not easy
emilio: Also what do we do for overflow? If you have an abspos that's like 350px and intrinsic sizes are 400, do you show the abspos?
oriol: If you do thing of taking intrinsic contribution, then yes, you can have contents overflowing and you will have scrollbars and overflow
emilio: actually we do a min-content check to find the height...
oriol: You'll get one word per line?
fantasai: Are the extensions in question with intrinsic sizes?
carlosj: Often fixed width and content-based height
emilio: What we do depends on form factor.
… The browser must impose a max-width and max-height
… and then you either do this intrinsic size, or let popup pick an explicit size?
… Popup needs to communicate to browser what it's preferred width/height are. The rest can be inferred, probably.
… API for that seems fine
… working off requestedheight/requestedwidth seems fine to me
fantasai: Remind me what that was?
emilio: So page inside iframe would communicate out their preferred size by these attributes on the root
fantasai: Could it ask for a content-based size?
emilio: Could use JS to set it to scrollHeight
carlosj: Didn't do it automatically to avoid authors doing bad things
emilio: Supporting these attributes on extensions is similar to what we do to day
<emilio> fantasai: the difference than what we're doing today is the autosizes
<emilio> ... what we're doing is that the author can set the size of the root element to communicate the preferred size
<emilio> ... but the root element is still that size even if it's given a different size
<emilio> ... so there's no way to say "i want to be 500px if I'm not autosized"
emilio: so I propose for the webextensions code to read the requested* attributes
… so yeah, we need some extra information
… idk how webextensions group specifies these things
… but that seems doable.
… set your preferred size with these attributes
emilio: Other thing that came up is, you might want to change size depending on font size. E.g. '30em'. Can do manually in JS, but not great.
fantasai: what if these attributes take CSS <length> ?
emilio: Then have to define when they're computed
… if there's a dynamic change to the root element's font size, need to resize
… in Firefox, the dialog asks for sizing, so you know when you're measuring.
<emilio> fantasai: length values changes when viewport or root font-size changes
<emilio> emilio: or zoom
fantasai: so change based on this
<emilio> fantasai: so should be easy to watch for
emilio: what if you have an MQ that sets it?
carlosj: There's a variable width here, ideally an extension can handle both
… don't think these attributes would solve that
emilio: If you have a display-mode MQ then can resolve that
… you would set preferred width and height, but you don't necessarily honor the preferred size if it's fixed size
emilio: First, need a better idea of what other browsers are doing
emilio: then maybe experiment with these attributes and try to standardize some form of these attributes
emilio: the MQ is probably still useful, and that can be brought to CSSWG
emilio: I think that's a good start?
SUMMARY: move forward with investigating the requestedwidth/height attributes and a new display-mode
Slideset: https://
<Bert> i|Slideset: https://