Meeting minutes
<salvehh30> Present
<castastrophe> Loving the project boards!
astearns: we are skipping introductions today, because it seems the people are about the same as the last time
astearns: if people have comments about the order, now is the time
[css-fonts] Computed value of font stretch
<astearns> github: https://
emilio: the spec has a note that says that for compat reasons, computation of font-stretch should stay a keyword if it was one, instead of the percentage
emilio: webkit doesn't do that
emilio: tests either require one or the other, there is no concensus
emilio: I would like to remove this note
myles: there is no known issue I was working around
dbaron: usually, we try to stick to the most compatible representation for compat
emilio: returning the keyword makes it difficult for authors because they need to reverse compute the keywords
emilio: font-3 used to report the keyword all the times
myles: at least in webkit, we implemented font-stretch at the same time as the numerical values
myles: so the span of time where we didn't support numbers for it was short
myles: possibly not even a release
dbaron: given that, I think it's fine to break the general principle
astearns: ok, so the proposed resolution is to not used the font-stretch keywords in serialization
emilio: and return a percentage
astearns: ok, any objection to this?
Resolution: font-stretch should serialize to a number/percentage, not a keyword
[css-fonts] extent font-size-adjust to take a pair of values: <metric> <number>
<astearns> github: https://
jfkthame: this was prompted by the discussion about size adjust descriptor
jfkthame: we want to harmonize when we have mixtures of fonts
jfkthame: font-size-adjust allows you to use the x-height of the font to size things
jfkthame: this is very latin-centric however
jfkthame: for exemple you might want to harmonize the ascent/descent of the font instead
jfkthame: because x-height might be meaningless to my language
jfkthame: this sounds like a natural extension to me, but I wanted feedback
fantasai: this makes sense to me
fantasai: I support the proposal
florian: same
florian: I would like to note that the ascent+descent combination is problematic
florian: because it depends on the baseline
florian: it's easier to stick to things that are distances from the baseline
florian: otherwise you adding/need to add adding a feature to realign
jfkthame: I don't propose to adjust the alignment
jfkthame: just the font size
fantasai: yes, you would need to use ideographic alignement in some cases
florian: ok, that sounds convincing, you can use vertical-align to deal with any alignement problem
myles: did we consider IC-height?
<florian> [IC = Ideographic Character]
fantasai: we probably want to have logical variants of these as well
myles: philosophically this proposal makes sense
myles: but to change the spec, I will need a list of tokens to consider for the first argument
myles: I might have some opinions on the set
myles: descent doesn't seem useful for example
astearns: how often do people use font-size-adjust?
fantasai: it's not cross-browser so it might be lower than we think
jfkthame: I found a lot more uses that I expected actually
jfkthame: but however it often as no effect since it only applies if font don't load
astearns: are we sure we don't complexify too much?
fantasai: I think it's fair to support non-european languages better
fantasai: some languages don't even have opentype metrics, but at least this would add support for languages for which we have metrics
<fantasai> s/non-european/
fantasai: and it provides a design which works to add new metrics if they are created later
astearns: which browsers support this right now?
myles: probably just firefox?
jfkthame: and behind a flag in chrome
myles: and webkit would implement when we add the overrides in the font description block
myles: no objection to add, we can discuss the set later
astearns: sounds like we have a consensus
astearns: any objection?
Resolution: add new metrics that can be used to harmonize the font size of fonts used in fallback
florian: btw we need to find a way to work with the opentype people
florian: so we can provide feedback
florian: I don't have a plan to propose, but there is a community group created recently
florian: I don't know for sure how to engage with the fonts people, but it would be nice to figure it out
astearns: indeed, the set of metrics can be a good think to ask to the opentype people
astearns: let's make sure that we don't ping them about bad fonts though
astearns: there are lots of fonts that are reporting wrong metrics
astearns: and it's not the fault of the committee
<florian> https://
[css-fonts-5] vertical metrics overrides
<astearns> github: https://
fantasai: these overrides are useful if you rotate the font (?)
fantasai: for example ascent and descent are given differently depending on the axis
fantasai: but we probably need to add values that would override things in vertical writing mode
fantasai: because using the horizontal values in vertical writing mode doesn't make any sense
myles: in upright vertical text, the ascent would be horizontal?
fantasai: yes, horizontal
(some pondering)
astearns: do we need to support both or a switch?
fantasai: I think both might be required to be specified at the same time
myles: this proposal would require a different implementation
myles: this is fine, but this something worth noting
fantasai: but the font has y values, you just need to override them
myles: possibly? but the problems that this solves are less important that the horizontal writing mode
fantasai: I would agree that this is less severe in most cases
fantasai: because in vertical writing mode the baseline is often the middle, and it is fine
myles: and the CJK scripts don't have diacritics so they usually fit in the 1em box
fantasai: some cases might still exist
astearns: are there arguments to not complexify?
astearns: if we add this, I would like to view examples
astearns: because I don't have an idea in mind of what this would do
astearns: any objection to add this to the spec at this time?
jfkthame: line-gap override could be useful too
jfkthame: no reason this should be left out
astearns: ok, any objection?
Resolution: add font-face descriptor overrides for vertical writing modes
[css-fonts-5] How do font-size-adjust property and size-adjust descriptor work together?
<astearns> github: https://
jfkthame: the question came up about the interaction between these two properties
jfkthame: the proposed solution in the issue
jfkthame: is that the font-size-adjust takes precedence in a given element
jfkthame: that does erase the changes in the descriptor
jfkthame: I think this makes sense
myles: one way of looking at it is that they both occur, but font-size-adjust changes things to the same solution regardless
myles: when writing the spec text, I would go with this
jfkthame: I think that is true
<dbaron> (Myles's description makes sense to me.)
jfkthame: basically the calculations of font-size-adjust cancel out any previous adjustment
astearns: sounds like we have a general agreement
astearns: any objection to this clarification?
<fantasai> +1 to jfkthame's proposal
Resolution: clarify that font-size-adjust computations will effect things in such a way that the descriptor overrides have no effect
[css-flexbox] [css-sizing-4] Interaction of flexbox minimum height and aspect-ratio minimum height
<astearns> github: https://
cbiesinger: the aspect ratio spec says that min-height auto and you compute it using the aspect ratio, you expand to the content height
cbiesinger: but in a column flex box, the height is the minimum of the transferred height and the content height
cbiesinger: it's not clear to me which one should win
cbiesinger: fantasai clarified the aspect ratio version should win
cbiesinger: but does the working group agree to this?
fantasai: this is different for replaced and non-replaced elements
fantasai: because the intrinsic size of replaced elements is not as strict
fantasai: so we need to keep that behavior for them
fantasai: but for non-replaced elements, the intrinsic size is more meaningful
florian: I'm not sure about what the alternative is?
cbiesinger: width:100px + aspect ratio 1:1 but intrinsic-height:200px
florian: ah ok, got it
cbiesinger: because it used to be the minimum
jensimmo_: the default of flexbox is that it's shrink then grow
jensimmo_: but the proposal is that for replaced elements, we make aspect ratio "work"
fantasai: yes, that is the heart of the issue
(some discussion about magic css jokes)
astearns: last week there was more contention
<fantasai> [jen's explanation was that if there's a bunch of elements you want to be squares, unless too much content want to grow, that's the behavior we specced for block boxes with aspect-ratio; and the issue is making sure it works the same for flexbox]
iank_: that was me last week
iank_: I am now fine with this
astearns: is the spec edit correct for what we discussed
fantasai: I think it is correct
fantasai: but we need to update the spec
fantasai: proposal is non-replaced elements with an aspect ratio honor the intrinsic size in flexbox
<cbiesinger> for min-height:auto
jensimmo_: I am seeing a lot of tutorials about aspect ratio on replaced elements
jensimmo_: in particular object-fit/ I think? etc
fantasai: that should continue to work
fantasai: that is why we don't do this for replaced elements
fantasai: non-replaced elements have an intrinsic size that depends on content, that might not be easy to resize
jensimmo_: the previous text for images would still apply then?
fantasai: yes
astearns: any objection to keep fantasai's edit in the ED?
Resolution: non-replaced elements with an aspect ratio honor the intrinsic size in flexbox for min-height:auto
<br length=15min />
<leaverou_> Partial regrets for Chris, he's having a migraine. May join later
TabAtkins: might be a dwarf propaganda map, hiding their continent from the view of others then! that would be smart of them...
<TabAtkins> House Sivis is gnomish, not dwarvish
[css-sizing] Auto-resize iframes based on content
<TabAtkins> https://
<TabAtkins> github: https://
TabAtkins: Fairly old issue, #1171
TabAtkins: originated in HTML in the form of 'seamless' attribute on iframes
TabAtkins: meant to allow isolating parts of a page, but still lay them out as if in the page
TabAtkins: there were a bunch of issues, dropped from HTML
TabAtkins: core ideas still requested by people, in various variants
TabAtkins: We believe there's a useful and safe set of resizing behavior that we could expose now
TabAtkins: that would solve some of the use cases
<TabAtkins> https://
TabAtkins: Core idea is that just the resizing portion of seamless is value
TabAtkins: But security issues around being able to tell the size of 3rd-party content
TabAtkins: bare minimum, different sizes of content depending on logged in or not
TabAtkins: So should only be allowed to take size of 3rd-party content if it wants to allow that
TabAtkins: Another problem, if 3rd-party page can trigger resizing without consent of containing page, can create problems as well
TabAtkins: So 2-way agreement on sizing
TabAtkins: First, outer page needs to opt into resizing based on iframe content
TabAtkins: Suggestion is to use new 'resize' value in 'allow' attribute
TabAtkins: Then for 3rd-party content, there's a window.resizeTo() method which is a no-op in iframes
TabAtkins: Inner page can request such sizes
TabAtkins: using this API
TabAtkins: Whenever inner page wants a resize, triggers an event on iframe which bubbles up
TabAtkins: if not prevetnDefault, then the iframe changes it's size
TabAtkins: if cancelled, doesn't change size
TabAtkins: This allows control over layout behavior across the page
astearns: Possible scripts using resizeTo() and relying on the fact that it does nothing?
TabAtkins: it's a no-op currently, so don't think so
TabAtkins: ... [ missed ]
astearns: Making page decide to allow event or not, already in place due to opt-in to resize behavior
cbiesinger: Nothing sounds like CSS thing
TabAtkins: kinda sorta
TabAtkins: it's a cross-spec thing, does interact with CSS by adjusting intrinsic size of iframe
TabAtkins: gets into issue of same-origin content
<TabAtkins> fantasai: YOu wanted a 2-way handshake for security
<TabAtkins> fantasai: resizeTo() gives you 2-way for page consenting
<TabAtkins> fantasai: If that page is already firing resizeTo() and expecting it not to ahve sec implications
<TabAtkins> fantasai: I don't think paying attention to resizeTo() would break the framed page...
<TabAtkins> fantasai: But if they're asking for it and it's currently not changing size, the outer page probably isn't expecting a problem.
<TabAtkins> fantasai: [clarifying] the issue isn't an attack due to sizing, it's a possibly unexpected info leak from the frame'd page, leaking the size it wants to size to
florian: currently, calling resizeTo() doesn't leak information
TabAtkins: could check if stuff in iframes do this currently...
fremy: It's not about stuff currently in iframes, but a page could put *anything* into an iframe
fremy: which would leak information from that page, which was not intended to be in an iframe
florian: resizeTo() doesn't have an effect on pages that are loaded into a window with multiple tabs
florian: for exactly this reason: it would leak information about that page to other pages in the same window
<Zakim> florian, you wanted to ask at which level of sizing this works. natural size of the iframe? something else?
florian: opening up this leak through iframes is similarly bad (worse maybe)
<iank_> another path would be an additional dictionary argument to resizeTo, e.g. window.resizeTo(100, 100, {something: true});
TabAtkins: Yeah, OK, we need to think about that more. Maybe needs a new API
+1 iank_
florian: In the case where resize does work, thing it affects is the natural size, right?
TabAtkins: Yes. Right now iframes have natural size of 300x150, and this would change that
TabAtkins: totally controllable, it's the weakest size input possible
fremy: do iframes have an aspect-ratio applied to that intrinsic size?
TabAtkins: currently iframes do not have an aspect ratio
TabAtkins: Ability to infer an aspect ratio is an interesting possibility
florian: As long as we're there, should we specify min size and max size separately
TabAtkins: Interesting. Not unreasonable to consider.
jensimmo_: Curious about use cases
jensimmo_: All I can think of is what ad networks will do, and I don't like those thoughts.
TabAtkins: There's another proposal for 1st-party content, which addresses more use cases
TabAtkins: but even within 3rd-party stuff, currently they do this resizing already, just with postMessage back and forth
TabAtkins: This would standardize that
TabAtkins: There's also things like Disqus, which does such special-case postMessage things
TabAtkins: which is complicated and no standardized way to handle across multiple systems
TabAtkins: YouTube player, e.g., might want to do this. CodePen might want to ask for sizes on its examples. Anything that wants to embed, has a reasonable use case for wanting to request a particular size and have it potentially honored by containing page
jensimmo_: If goal is to reduce jankiness of ad network...
TabAtkins: that is one goal, but not all of it!
<leaverou_> need to drop off briefly for another call, but I'm very supportive of this, and I hope we can find a way to implement it in a privacy and security preserving way.
emilio: How do you react to resize in parent page when using the API?
emilio: User shrinks the page, need to somehow coordinate between both. No auto size, only fixed intrinsic size
TabAtkins: I don't think there's a reasonable direct analog to block auto-sizing ..
emilio: I guess at that point... You don't really need JS on the parent page to get auto height
emilio: If you require JS on the parent page then it's not great
emilio: So inner page can send resizeTo() whenever it gets Resize event
emilio: and then containing page doesn't need to do anything ...
emilio: [missed]
TabAtkins: possible this makes it easy enough that it's a concern
emilio: resize event ... your own resize event
TabAtkins: I suspect that's something that would show up fairly quickly
emilio: It only consumes CPU, not while:true. I send a message, it resizes me, sends a message back. Code keeps working, just uses a ton of CPU
emilio: It's a bug in the page, but.
TabAtkins: no-op loops can't happen because if the iframe's resizeTo() doesn't change its size, won't get an event because size didn't change.
TabAtkins: Either it'll grow or shrink infinitely, or will jiggle, which should be noticeable
emilio: Concerned about e.g. floating point issues, and rounding errors
emilio: I've seen that kind of stuff happen
<iank_> we also already have the "jiggle" problem today with frame by frame resize-observers.
if not causing change in size, then shouldn't cause a problem
fremy: can't put a breakpoint in the main page to figure it out because no JS
fremy: Already have these kinds of bugs today
smfr: The HTML5 event loop spec is very specific about when resize steps happen
smfr: when we spec this, we need to spec it in terms of that event loop spec
smfr: Nobody mentioned resizeobserver yet
smfr: it's designed to avoid infinite recursion
smfr: we might need something here with nested iframes, so don't get into crazy infinite resizing
TabAtkins: yes, want to handle events in descending order like resizeobserver does
TabAtkins: need some thought to ensure not creating bad cross-tree resizing behaior
TabAtkins: Not too concerned about page vs iframe vibration, but much worse if grandparent grandchild interactions cause problem, because then nobody knows what's going on
fremy: Main question here was, I guess point of allow attribute is to allow resize
fremy: External page wants to allow iframe to resize
fremy: Not sure I understand point of resize function
fremy: why not some CSS value that allows resizing by containing page
fremy: reason I think about htat is that resize takes 2 arguments, width and height.
fremy: not that interesting to change intrinsic width of iframe
<gregwhitworth> +1 to fremy
fremy: why not say that "I'm fine with my scrollHeight to be reported to the containing page"
iank_: scrollHeight isn't always what you want
fremy: could be something smarter, max-content maybe
TabAtkins: Second part of proposal also, about same-origin content and no-JS solution
smfr: Other point, iframe calls resizeTo() and has to provide a size. What size should it provide? does it doe getBoundingClientRect() on the body or what?
smfr: Is there some convenient way to get the height of the content?
TabAtkins: For 1st-party content, making it easy. But for 3rd-party content wanted to be more explicit
TabAtkins: But maybe we can reduce that restriction
TabAtkins: 2nd part of proposal is about same-origin content
TabAtkins: right now, minimum solution still requires some JS on the framed page (not containing page)
TabAtkins: but for same-origin content, there's a certain degree of implicit trust we can rely on
TabAtkins: and might not require auditing
TabAtkins: for this, I propose that on a 1st-party iframe, or something that's srcdoc
emilio: srcdoc is not ?
emilio: data URIs are
TabAtkins: sorry, I'm thinking about sandbox
TabAtkins: In my original proposal, I had a new property that could be set on the root element to set the requested intrinsic size for each axis (auto | <length>)
TabAtkins: page could opt into ? via 'from-element' keyword, providing fallback length
TabAtkins: fantasai later suggested the page could just set an explicit width/height on the HTML element
TabAtkins: Possibly we don't need to mint a new property, can just take from the root element
TabAtkins: if that's problematic from existing, maybe mint something new
TabAtkins: but either way, that'll allow getting the size without JS
TabAtkins: Just set allow=resize, and inner page does whatever it needs to do
TabAtkins: and those sizes automatically communicate back and forth
TabAtkins: acts like an element, no JS required
<TabAtkins> https://
fremy: that only works in 1D, right? you can't do both dimensions
fremy: then you wouldn't get the resize
fremy: if you get width + height, wouldn't know you need more space
TabAtkins: If you set both to auto, you'll need to rely on outer page to set your width...
fremy: ah, ok, make sense
iank_: I don't think that width/height on HTML will work, because people do set an explicit width on HTML and use e.g. auto margins to center
iank_: HTML is not the root, bit of disconnect
iank_: likely for auto behavior, might want something like scrollWidth/scrollHeight as was discussed
iank_: There's a little bit of danger here
<fremy> +1 to scrollWidth/scrollHeight (adjusted if necessary)
iank_: you might get content that, if you have a fixed-position content that rises to ICB, and has height 120%, could create an infinitely-growing iframe that way?
iank_: I'm not too concerned about that
TabAtkins: Yeah, need to think about loop detection...
fremy: we can set a threshold, if you fire too many resize events in a certain amount of time don't allow it or whateer
iank_: That might block some valid use cases. E.g. comment expansion might want to animate growing
<gregwhitworth> resizeObserver has the same error handling
gregwhitworth: Effectively what you just outlined is something we wanted at Salesforce. All over the web ppl using Salesforce but not aware of it.
gregwhitworth: would like to see network headers
gregwhitworth: enable this auto behavior for cross-origin
gregwhitworth: if a grid with min/max content, how can I lay out my content and pass back my height
gregwhitworth: I can work it out in JS, but want it automatic
TabAtkins: Reason restricted right now is trying to be cautious
gregwhitworth: we could write blog posts about how to do it, but would rather not
TabAtkins: I would want to have more security eyes on it
gregwhitworth: ...
emilio: There is some kind of precedent for this, loading a doc and sizing it intrinsically, which is SVG
emilio: Even if the SVG is not an actual image, if you have an object tag with SVG source, that's actually a document that's ...
emilio: in FF and Chrome at least, that size is intrinsic to SVG's viewbox
emilio: it would be good to figure out if there's something that we need to learn from that or not
emilio: that's probably legacy behavior
emilio: While we were doing site isolation
emilio: I just wanted to mention that precedent
emilio: I think those can run script, even if SVG
TabAtkins: A few people in thread mentioned OBJECT
TabAtkins: If currently allows that behavior and think it's OK, then maybe can allow it
TabAtkins: I haven't thought about it yet
<TabAtkins> fantasai: on the topic of 3rd party sizing info without JS, I think i tmakes sense to allow
<TabAtkins> fantasai: If both the container and the inner page have explicitly allowed for it
<TabAtkins> fantasai: That indicates trust between the two
<TabAtkins> fantasai: For doing it declaratively, Ian's pointa bout width/height on root not being what we want makes sense
<TabAtkins> fantasai: Tab mentioned setting a property giving the behavior explicitly
<TabAtkins> fantasai: I don't think that's a CSS property, it's more of a security handshake
<gregwhitworth> +1 fantasai
<TabAtkins> fantasai: So maybe an attribute on <html> that opts the iframe'd page into the behavior
<TabAtkins> fantasai: And would let you specify which size you want (scroll height, border-box height, etc)
fantasai: I think the size shouldn't be specified in HTML, should be in CSS; but allowing this should be an HTML attribute
dholbert: Should any page on the internet be able to get that info?
dholbert: maybe same-origin addresses it
dholbert: don't want to allow inadvertent stealing of info from the page
TabAtkins: right, which was why I initially wanted to disallow it
TabAtkins: and fantasai was talking about explicit opt-in
TabAtkins: I think there's some kind of iframing options setting?
iank_: There's ??? HTTP Header which restricts which origins you can be embedded in. Most banks etc. use that.
TabAtkins: requiring that, reasonable thing to start with
iank_: would need to set Access-control: allow-origin or whatever
astearns: Sounds like you got some good feedback, something to work on
TabAtkins: plan is that parts of this that relevant to CSS would go to contain spec
TabAtkins: and sizing spec
TabAtkins: to talk about natural size being controllable this way
TabAtkins: if we do have a new property... probably in sizing? maybe contain?
TabAtkins: rest will be pursued in HTMLWG
astearns: Should CSS part depend on the HTML part being accepted?
TabAtkins: sure
myles: This entire discussion about how / technical considerations. Not about whether to do it all.
myles: Want to make sure that it's not a foregone conclusion that we should do this.
TabAtkins: Decent part of this was sussing out whether there's interest in doing this
TabAtkins: seems people are interested
TabAtkins: I suspect discussion in HTMLWG will be more contentious
TabAtkins: OK to object over there :)
astearns: but feel free to object over here also, if you think it's a terrible idea!
TabAtkins: We don't have any major internal partners clamoring for this, it's an old issue that's a frequent author requested, and we found a way to address an important part of it
<TabAtkins> <br dur=12min>
<br duration=12min>
[css-values-4] Add lvh+lvw values
6113 is a specific part of 4329
<faceless> </br>
[css-values-4] Add lvh+lvw values
github: https://
github: https://
<TabAtkins> fantasai: 6113 is a specific part of 4329
<TabAtkins> fantasai: 4329 is a long discussiona bout how people are really, *really*, REALLY unhappy how on mobile the viewport units don't represent the size of hte viewport
<TabAtkins> fantasai: And the reason is that there are parts of the browser chrome that appear and disappear dynamically as you scroll
<astearns> +1 to unhappiness
<TabAtkins> fantasai: so a bunch of UAs decided that the viewport units are the size of the viewport with all the dynamic chrome hidden, so a 100vh element will be partially obscured if anything *is* showing
<TabAtkins> fantasai: Which is fine for some content, and really obnoxious for others (like toolbars or headers that have to be attached at the top/bottom of the screen)
<TabAtkins> fantasai: So we've had a dsicussion about what values authors need to get the useful behavior.
<TabAtkins> fantasai: Three thrings.
<TabAtkins> fantasai: One is size of the viewport with chrome present, so they can size into that minimal space and never get things overlapped.
<TabAtkins> fantasai: Another is the size without the chrome, so they can size to the maximal space and get all the space filled when it's all hidden.
<TabAtkins> fantasai: And finally, the dynamically-changing current size with whatever chrome is currently showing, so it'll perfectly fit the viewport in all cases.
<TabAtkins> fantasai: Currently we are only providing #2, and that's a problem.
<TabAtkins> iank_: I thought vhc did change?
<TabAtkins> fantasai: No it's static, and also it's not defined yet because we haven't decided on a name.
<TabAtkins> fantasai: So the issue I tagged here is someone saying "how about we introduce lvh/lvw/etc" and that would represent the dynamic size of the viewport.
<cbiesinger> what does lv stand for?
<TabAtkins> fantasai: And then vhc would be the with-chrome static size, and existing vh would be without-chrome static size.
<astearns> cbiesinger: Layout Viewport height
<cbiesinger> ah
<TabAtkins> fantasai: In A Coruña we discussed this, and a suggestion was becuase of the way viewport units compute, and to emphasize the dynamic-ness, possibly exposing the dynamic version as an env() value instead of a unit.
<TabAtkins> fantasai: And that might be less scary to implement.
<TabAtkins> fantasai: Viewport units have to be computed whenever the window changes; making it happen on scroll would be worse.
<TabAtkins> smfr: Drill down on "dynamic change"
<TabAtkins> smfr: in iOS, when the chrome animates in, I don't think we'd animate the unit; we'd snap it.
<TabAtkins> smfr: We ahve a notion of the UI being in an unstable state.
<TabAtkins> smfr: Like, position:fixed is magic that happens in the compositor.
<TabAtkins> smfr: Web content doesn't see the dynamic change, it sees things flip, and the dynamic stuff happens behind the scenes.
<TabAtkins> fantasai: I think that's fine, as long as the layout is correct when UI is stable.
<TabAtkins> fantasai: If the in-between state is optimized in ways that's probably fine.
<TabAtkins> fantasai: Someday animating it might be nice and performant, but for now it's fine. From the author's POV, it's the end states that matter.
<TabAtkins> TabAtkins: I agree, it seems like the end states are th emost important here
<TabAtkins> emilio: Same about end states, and that Firefox Mobile uses similar concepts. Webview only knows about the final states, not intermediate.
<TabAtkins> emilio: Also this sounds like fullscreen, a bit. We ahve display-mode MQ which tells you some stuff about the browser screen.
<TabAtkins> emilio: Would having these units and an MQ to switch between them work?
<TabAtkins> TabAtkins: Don't understand what you mean.
<TabAtkins> emilio: Instead of having a dynamic unit, just using the vh or vhc based on an MQ.
<TabAtkins> fantasai: I do want to keep it open for the future to be animated.
<TabAtkins> TabAtkins: I think this supports that, if we don't do dynamic *at all* right now.
<TabAtkins> fantasai: The computed-ness is still problematic
<TabAtkins> emilio: Computed value will *definitely* change with env(), they get substituted at var() time
<TabAtkins> fantasai: Or we have a unit that is used-value time. I don't think people need computed behavior here.
<TabAtkins> emilio: We ahve this already with %s on a fixpos
<TabAtkins> iank_: Yeah, or % height on <html>, they dynamically change based on chrome showing. So this concept is already exposed.
<TabAtkins> iank_: So given the existence of height:100% on these elements, I don't know if we should try to avoid exposing this by using the MQ path.
<TabAtkins> smfr: height:100% doesn't change on iOS
<TabAtkins> emilio: It does for fixpos on Gecko, but unsure about on <html>
<TabAtkins> emilio: This is historically not the most interoperable bit of mobile engines...
<TabAtkins> emilio: Could we spend some effort figuring out what we want the existing primitives to do?
<TabAtkins> fantasai: Yes, but I think we also need to add the new ones.
<TabAtkins> fantasai: Either way we'll need these three kinds of values.
<iank_> here is a testpage https://
<TabAtkins> fantasai: Deciding which one the height:100% maps to is probably a little more acceptable once we have the ability to change to another one, via new units.
<TabAtkins> fantasai: But right now people are just very unhappy
<TabAtkins> chrishtr: Is you set vh units it's the full size, ignoring chrome.
<TabAtkins> chrishtr: If you use vhc it subtracts chrome, so if yous croll up you see a gap
<TabAtkins> chrishtr: lvh theoretically animates, but at least shows the right value on stable. If you don't animate it'll show a gap during unstable, and then snap.
<TabAtkins> fantasai: One thing you can do is make the animation always snap to the larger size.
<TabAtkins> fantasai: It doesn't have to be the size you started at, just one of them; using the larger size always sounds better.
<TabAtkins> chrishtr: So when you start the animation, snap to the larger thing, do a main-thread relayout and possible introduce jank to the browser's interaction model.
<TabAtkins> chrishtr: Layout could take time, there could be a rAF callback...
<TabAtkins> fantasai: Right, but I think making it pretty is secondary to making it usable at all.
<TabAtkins> chrishtr: I find the whole area pretty confusing for ideal UX.
<TabAtkins> fantasai: Example: I've got a coding tutorial page, with pretty pictures.
<TabAtkins> fantasai: Long scrolling page.
<TabAtkins> fantasai: The elements I want to be viewport height are pictures and code blocks, both scrollable.
<TabAtkins> fantasai: It's *really awkward* to have a scrollable block taller than the viewport.
<TabAtkins> fantasai: So for usability reasons I want the code block to be at most th eheight of the viewport.
<TabAtkins> fantasai: But I want the viewport size *with chrome factored in*, the smaller size, so it'll always show the scrollbar when needed.
<TabAtkins> fantasai: I don't want larger (overlaps) and I don't want dynamic; I just want to make sure the entire box is visible when it's on screen regardless, so I can access both scrollbars.
<TabAtkins> fantasai: But for the pictures, I want them to fill the viewport, but it's okay to ahve them be cropped a bit.
<TabAtkins> fantasai: So I want them to fill the whole viewport when the chrome is hiding. And it's okay if the chrome comes in and obscures a little of the top or bottom of the image.
<TabAtkins> fantasai: And similarly I don't want this to be dynamic, because it'll cause the page to shift around, I want stable.
<TabAtkins> fantasai: And then *thirdly* I could have a sidebar that wants to fill the height of the page, and it needs to be dynamic - using all the height that's available when chrome is hidden, but not cropping anything when chrome is showing.
<TabAtkins> fantasai: So we want all three behaviors; we want to make sure that dynamic behavior is *clear* and won't get reached for accidentally.
<TabAtkins> chrishtr: So the sidebar example wants the dynamic example, right?
<TabAtkins> fantasai: Yeah.
TabAtkins: Have problems with the toolbars currently, even with position:fixed. [gives example]
<TabAtkins> iank_: People do dialogs, for example, that want it to fill the viewport, but too deep in the DOM to use 100%.
<TabAtkins> iank_: Ther'es a lot of examples.
<TabAtkins> chrishtr: So a fullscreen, or fullscreen minus margin, dialog, you probably want it to dynamically resize when you hide the omnibox?
<TabAtkins> iank_: Yes.
<plinss> https://
<TabAtkins> plinss: Microsoft is doing some virtual keyboard API (link), wanna make sure we coordinate with this work
<TabAtkins> iank_: I think this is a slightly different usecase here
<TabAtkins> iank_: I don't think you want lvh to change on keyboard showing
<TabAtkins> fantasai: I agree with Ian, and think we discussed this in A Coruna as well and came to the same conclusion.
<TabAtkins> fantasai: Wanting keyboard to change your layout is something much less common you should opt yourself into.
<TabAtkins> iank_: Especially like adding an extra keyboard above the UI keyboard
<TabAtkins> astearns: If that's the case, I'd want to see noted the reasons why we're explicitly not doing that.
<TabAtkins> fantasai: Sure, we can add a note for that.
<TabAtkins> smfr: I think there's a diff on Android vs iOS for whether keyboard is an overlay vs viewport shrink
<TabAtkins> smfr: There's also the visual viewport API that tells you when it changes due to the keyboard
<TabAtkins> dlibby: There's three modes - keyboard resizes the layout viewport (Android), keyboard resizes the visual viewport (Windows/iOS), and virtual keyboard is third (nothing page-observable happens besides some events firing)
<TabAtkins> dbaron: One thing to be careful about with dynamic unit is that there's an assumption that users will make some scroll gesture, and the toolbar will appear or disappear, and the unit will resize things, and somehow there's magic that'll happen that puts things in the positions they're expected to be in.
<TabAtkins> dbaron: I think we shoudl be careful not to assume that magic will just work, because it's actually quite hard. When things resize, things move.
<TabAtkins> chrishtr: You mean hard for the dev to make sure things move in predictable ways?
<TabAtkins> dbaron: Possibly both. I think there will be unexpected results where they use the dynamic unit, get the right size, but not the right position.
<TabAtkins> florian: Right, and I don't think in general you can't guarantee anyway because too much of the layout has changed.
<TabAtkins> chrishtr: What do you mean by position of content?
<TabAtkins> florian: If your page is just a linear stream of content, and you're just using the unit for height, you can expect the position of th eresized bit to not change.
<TabAtkins> florian: But if you use the unit in width, and this changes how many columns fit, etc, there might be arbitrary layout changes on the page that make it undefined what it means to be "same position"
TabAtkins: 2 items, both 100lvh
TabAtkins: both change, and bottom one ...
TabAtkins: causes unexpected position changes
<TabAtkins> smfr: Scroll anchoring can probably help ther
<TabAtkins> TabAtkins: Agree
<TabAtkins> smfr: If this is a unit that changes value, we need an event to inform you of the change. Possibly this is the resize event; if so, we need to sync this unit changing with th eresize event firing
<TabAtkins> fantasai: Does resize change due to this?
<TabAtkins> smfr: We do fire the resize event....
<TabAtkins> smfr: It fires on inner height, which does match this I think
<dlibby> visualViewport resize does fire already, I believe
<TabAtkins> smfr: There's several things that need to be accounted for.
<TabAtkins> iank_: I posted a testcase a bit ago, that should show in a particular browser when things change based on user gesture
<TabAtkins> iank_: I think resize event should fire when innerHeight changes
<TabAtkins> florian: Could this get us into loops, if the content using the viewport units gets smaller than the viewport height?
<TabAtkins> fantasai: We can get into the details for that after we decide whether to do this or not at all ^_^
<TabAtkins> fantasai: So we need to decide whether to add these functionalities or not
<TabAtkins> fantasai: If so, add them as units, as env(), as something else?
<TabAtkins> astearns: Are we lacking a second stable resolution?
<TabAtkins> fantasai: We have a resolution, just not a name.
<TabAtkins> fantasai: We don't ahve a resolution for the dynamic version.
<TabAtkins> fantasai: We should have consistency between them.
<TabAtkins> fantasai: The proposal for dynamic uses a prefix; we might want the small static one use a prefix as well, so cvh rather than vhc
<TabAtkins> chrishtr: Coming back to use-case for dynamic, a 100% height sidebar
<TabAtkins> chrishtr: Why can't that be position:fixed top/bottom:0?
<TabAtkins> iank_: It can, but often people will embed sidebars deep in other elements
<TabAtkins> iank_: It'll break their site layout if it's fixpos
<TabAtkins> iank_: There can be a fixpos containing block between it and the root
<TabAtkins> iank_: People will often develop for desktop-first sidebars, and handle mobile after, and their page structure is already set.
<TabAtkins> florian: Another is you might not necessarily want to be on top of things. Think app, not document, with toolbars around a content area - a grid with toolbars in side cells and an overflowable center area
<TabAtkins> florian: Entire UI is supposed to fit the screen at all times. If browser chrome pops in and out, the page's UI shifts, but it should all always be visible.
<TabAtkins> chrishtr: So this is a site that doesn't scroll?
<TabAtkins> florian: Yes, the overall site doesn't scroll, just the regions.
<TabAtkins> jensimmons: Right, fixpos would work *only* if people were already using abspos for their layout, not if they were using Grid/etc.
<TabAtkins> jensimmons: Could we do a thing where we have units to measure the constant states, and then use env() for the dynamic things?
<iank_> (the units aren't constant if you change the window size :)
TabAtkins: That was fantasai's suggestion, to make it really obvious that this is dynamic and different from the others, make sure you really want it
<TabAtkins> chrishtr: Could one of y'all share an example that would help explain it?
<TabAtkins> florian: [shows off a music editing app on his phone, with a toolbar on bottom with sheet music taking up the content area]
<TabAtkins> florian: I always want the toolbar to be showing regardless of chrome showing or not, and I don't want the toolbar to overlap the end of the sheet music if I scroll to the bottom.
<fremy> @florian: isn't that position:sticky?
<TabAtkins> florian: So probably the whole thing is a Grid, with a height of env(viewport-height) or something, and the toolbar's grid cell is fixed height, etc
<TabAtkins> fremy: Wouldn't stickypos do this, too?
<TabAtkins> sanketj: yeah, seems like stickypos too
<TabAtkins> florian: My claim isn't that you couldn't do it with stickypos or whatever, but rather if you're thinking about your entire layout in Grid, which you might very well do because it's modern and convenient, you can express this all in Grid, but then if it fails on mobile because the viewport units don't work...
<TabAtkins> iank_: Important to think about is that web devs might start by developing with a grid, which is deep in the DOM; to size it to the viewport they need to size all the elements in the ancestor chain carefully. Using vh is a very simple and easy tool there. It's a big change in theinking to instead switch to fixpos or stickypos.
<TabAtkins> iank_: So If they started with this as a grid, and were sizing to `calc(100vh - 10px)` or whatever, it would be a big change.
TabAtkins: ...
TabAtkins: ...
TabAtkins: ...
TabAtkins: Want to make sure that we don't create cliffs
<TabAtkins> florian: And if you have stickypos, the toolbar needs to be a child of the scroller; in Grid it's a sibling of the scroller
<TabAtkins> jensimmons: The use-cases we've seen, attaching to the bottom, is *one* of *many* use-cases for viewport units; I've demo'd viewport unit a bunch on stage and have never even used this case.
<TabAtkins> jensimmons: And 100vh isn't the whole thing - 50vh items stacking is reasonable.
<TabAtkins> chrishtr: Returning to florian's app example, the root scroller doesn't have overflow, right?
<TabAtkins> florian: In a simplified version, yes, it's a flexbox that fills the viewport. The content area that contains the sheet music has overflow:auto.
<TabAtkins> chrishtr: So the interaction model they want is you can scroll the music, nothing else; you can always tap the play button.
<TabAtkins> florian: Yeah.
<TabAtkins> chrishtr: So in this case, when it first loads on chrome mobile, the url bar will show and then never disappear, since it only disappears if you scroll the root scroller.
<TabAtkins> cbiesinger: I think apps sometimes do a scrollTo(1px) to cause the URL bar to autohide
<TabAtkins> florian: That might explain why the Firefox behavior is so confusing/uncertain
<TabAtkins> chrishtr: Yeah there's bugs around that.
<TabAtkins> chrishtr: So the site could use vhc perhaps, but if they use the dynamic version they'll never see it adjust.
<TabAtkins> chrishtr: So I was concerned about this responding to user gestures hiding the bar - that needs to be smooth.
<fremy> totally agree with cbiesinger here. if you use a fixed grid over the screen, there is no way to auto-hide the chrome as a user, and the problem just doesn't exist in that case
<TabAtkins> chrishtr: But if it just needs to be resized to the correct new area, I can see the use for this dynamic unit
<TabAtkins> I know there's a proposal for a root scroller designation API floating around somewhere...
<TabAtkins> florian: So there's definitely a bunch of issues, but does it seem reasonable to take a resolution to pursue the dynamic thing, and possible scal eit back afterwards?
<fremy> @TabAtkins: Ah, yeah if such API existed, that could change things indeed
<TabAtkins> astearns: And are we shooting for a unit or env() ?
<TabAtkins> iank_: I'd err towards units, since that's waht webdevs are already used to.
<TabAtkins> iank_: I don't find the argument about dynamic changes compelling - the other units already dynamically change on window resize.
<TabAtkins> astearns: I think it's much more common for webdevs to resize the tab to check it responds properly, less experience with showing/hiding chrome on a mobile device.
<TabAtkins> fantasai: The nice thing about env() is that it's more obnoxious to use, so it's more of an explicit decision.
<TabAtkins> fantasai: On desktop it doesn't have this dynamic problem, only on mobile.
<TabAtkins> fantasai: So I feel like we'll get less people doing it by default.
<TabAtkins> astearns: People who teach CSS, do y'all have an opinion?
<TabAtkins> jensimmons: I could go both ways.
<florian> +1 to fantasai's obnoxious-on-purpose syntax argument
<TabAtkins> jensimmons: vh means the most pixels, vTBA means the least pixels, and both are fixed.
<TabAtkins> jensimmons: A third unit meaning a dynamic changeable value, that could be confusing to people.
<TabAtkins> jensimmons: But iank_'s point is compelling, where authors are already used to these as units.
<TabAtkins> jensimmons: But elika's point about this being an env() so people ahve to go look for it might make sense.
<TabAtkins> rachelandrew: My gut is a unit, same as the others, but I get how we don't want it to be the default people use, and making it look different can help there.
<TabAtkins> rachelandrew: So as a teacher, units are easier to teach, but I get the reasoning behind the other.
<TabAtkins> leaverou: I think it makes more sense as a unit, due to symmetry.
<TabAtkins> leaverou: Might be easier to read as an env() because it can have a longer name; unit names are cryptic.
<TabAtkins> leaverou: But env() names can get pretty long, especially in calculations.
<TabAtkins> iank_: There's already polyfills for this; they act like a unit setting a css variable.
<TabAtkins> That sounds like it's similar to env(), then?
<TabAtkins> astearns: I propose that we resolve to work on this dynamic unit. Get spec text together, with examples, and open separate issues for moving it to env(), what to do with animations, etc.
<TabAtkins> chrishtr: I think that sounds great, one more thing, I hope we can go forward with vhc as well.
<TabAtkins> astearns: We do have a resolution for that, we just haven't gotten it into the spec
<jensimmo_> I always find answering questions like this (unit vs environmental var) are easier to understand when I code some demos. Actually write out the code.
<TabAtkins> fantasai: And haven't decided on the name. And it might make sense to make sure these are consistent.
<TabAtkins> fantasai: Might all work best with a prefix.
<iank_> https://
<TabAtkins> fantasai: I propose to use "s" as a prefix for the small, static size, and "d" as a prefix for dynamic one.
Resolution: Work on the dynamic unit.
<TabAtkins> chrishtr: Not only do we hear a lot that this is a problem, Chrome is def interested in exploring this and working with devs.
<TabAtkins> chrishtr: If anyone has partners who can work with us, or has more examples, please contact me.
end
chrishtr: https://