W3C home > Mailing lists > Public > www-style@w3.org > August 2022

[CSSWG] Minutes New York F2F 2022-08-03 Part II: CSS Values; CSS Positioning [css-values] [css-position]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 31 Aug 2022 07:02:36 -0400
Message-ID: <CADhPm3uxQRssGjH6qRkewV7dku5qjpEqRdEz7ftBY4BpMdk-Vg@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Values

  - RESOLVED: Browser "fixups" of line height on form controls do *not*
              affect lh/rlh on the element itself. Effect of fixups on
              lh/rlh of descendants is explicitly undefined (Issue
              #3257: The lh and rlh units are more complicated than
              what they seem)
  - The group was leaning toward no change on issue #3135 (ch units
      shouldn't cause font downloads), meaning ch would continue
      triggering downloads. However, myles was not available for the
      call and was strongly against this approach so the group will
      wait on a resolution until he's available.
  - RESOLVED: Not adding units that trigger layout changes based on
              pinch-zoom (Issue #7194: Visual viewport units)

CSS Positioning

  - Discussion of various ways that UAs handle on-screen keyboards on
      mobile and how that interacts with fixed and sticky positioning.
  - There's a desire to get interop; but there's some heavy compat
      restrictions to navigate here.
  - There's also a desire to give authors more control in this area.
    Two proposals that came up were:
      * Environment variables representing insets from the viewport edge
      * New positioning scheme relative to the area excluding the
        Note: fantasai suggested distinguishing which viewport should be
              an independently cascading property rather than new syntax
              within the 'position' property
  - Discussion will continue in the issue


Agenda: https://github.com/w3c/csswg-drafts/projects/30

Scribe: TabAtkins

CSS Values

The lh and rlh units are more complicated than what they seem
  github: https://github.com/w3c/csswg-drafts/issues/3257

  emilio: I don't think this is too controversial
  emilio: fantasai added it to agenda
  emilio: Main issue is browsers have different line-height fixups
  emilio: sometimes at used, sometimes at computed time
  emilio: The ones at computed time should change the lh unit
  emilio: but that's not possible, you've computed everything at that
  emilio: At very least, would like to either agree...
  emilio: get interop on these adjustments
  emilio: so they don't cause weird interop issues

  emilio: The gecko adjustments are in the issue comment
  emilio: We force a minimum line-height on inputs at used value time
  emilio: for select we force line-height normal at computed-value time
  emilio: I believe these adjustments are done in other browsers, maybe
          in subtly different ways
  <iank> we do them differently.
  emilio: Forgot to look into details
  emilio: just don't know how differently

  iank: For some form controls we will look at the computed style and
        apply a bunch of fixups right at the end of computed style
  iank: so the two you're referring to will force it to
  <iank> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_theme_default.cc;l=201-205

  TabAtkins: I agree with fantasai, whatever we do here
             doesn't make any difference for real uses cases of lh/rlh.
             We will put anything you want in the spec, don't care.
  emilio: Agree, it would just be great to have those fixups documented
  fantasai: Further than that - I think having them documented is a
            nice-to-have. Don't really think they need to be interop
  fantasai: If people ship without interop on this one point, that's
  emilio: Given these fixups exist for webcompat...
  fantasai: Right, they're to make sure the line height doesn't shrink
            below usable for a form control
  fantasai: nobody's gonna depend on that for using lh or rlh on a form
  emilio: This is the sort of thing that always bites us
  emilio: I think this shouldn't be hard to get right
  fantasai: I'm totally happy to get it right. Don't want to delay
            shipping for 5 years for this one small detail that doesn't
  dbaron: I think if people have the lh unit they might sometimes use
          them for the height of a form control
  astearns: People will use the unit everywhere

  astearns: So ian is saying chrome's fixups are different...
  iank: Yeah ours are different than what emilio described
  iank: We just force, at least for select, reset it to initial
  iank: We've been slowly trying to remove these custom style fixups,
        but very gradually
  iank: You can imagine a lot of this depends on if the form element
        has auto appearance
  iank: so this is the difficulty
  iank: If we didn't have appearance, all of these could be UA
  iank: but we explicitly allow things to be overwritten if they don't
        have the appearance
  <emilio> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/text_control_inner_elements.cc;l=173-194;drc=7fe33e343d08dc8815b5ca48b96f76e98a3d67c7
           is for text controls,
           is for select
  emilio: Think I found the chromium bits
  emilio: Seems like in chromium you apply the fixups not on the
          element, but on the inner shadow dom of the control
  iank: Not 100% sure on that
  iank: thought we did some on the actual element

  astearns: So emilio, are you discussing putting these into the spec
            based on gecko?
  emilio: Not necessarily, just making sure lh/rlh don't change across
  emilio: It seems to me that implementing lh/rlh do end up with the
          wrong value, but wrong consistently
  emilio: so if you did a line-height less than 1, you'd get that value
          for lh unit even if the final line-height is 'normal'
  dbaron: I think the key question is whether the fixup changes what
          the lh does on itself, and on descendants
  dbaron: and if it's easy for impls to come to agreement we can just
          spec that
  emilio: Right and even descendants might not be too important for
          input, because replaced
  florian: Do any of these have descendants?
  emilio: Can set font-size on <option>, yeah

  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10518
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10519
  iank: These two examples show what we do with <select>
  iank: First has line-height on <select>, and we log 'normal' - it
        resets to initial
  iank: In second I set appearance:none and it logs 5px, so it shows
        fixup is dependent on appearance
  iank: We do all of this as a fixup step on the computed style at the
        very end
  iank: so an easy impl for us of lh unit would be these fixups apply
        at the end, and don't interfere with lh unit
  emilio: I agree that's the most reasonable thing to do
  iank: And a lot of people do set appearance:none if they want more
        styling control, and it'll work then

  astearns: So do we have enough?
  emilio: Yeah seems reasonable, as long as we agree that fixups don't
          change the meaning of the lh/rlh units
  emilio: firefox behavior is similar
  emilio: on <select> we do post-style fixup
  emilio: On webkit maybe the same, they do weird stuff on form controls
  iank: Yeah we've diverged a lot
  TabAtkins: So proposed resolution is that these fixups don't affect
             these units on form controls or descendants
  emilio: Descendants might get affected, since we do computed fixup
  emilio: but on the element itself it's clear
  iank: I think today for us if we apply this fixup, and some inner
        form control has line-height:inherit, it'll get the fixed up
        value, but don't think that's important
  dbaron: So if it affects descendants but not itself is interoperable,
          maybe specify it even tho it's weird
  emilio: Eh, we've got some todos to shift some computation to layout
          time rather than compute time
  emilio: Don't think it matters too much since it only applies to a
          few form controls
  fantasai: So can we spec it doesn't affect the form control itself,
            but undefined whether it affects descendants
  emilio: Yeah
  iank: Fine with that
  <emilio> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10520

  RESOLVED: browser "fixups" of line height on form controls do *not*
            affect lh/rlh on the element itself. Effect of fixups on lh/
            rlh of descendants is explicitly undefined.

ch units shouldn’t cause font downloads
  scribe: emilio
  github: https://github.com/w3c/csswg-drafts/issues/3135

  florian: We have multiple viewpoints represented, but are they enough?
  TabAtkins: Initial issue is that currently ch uses the advance of the
             0 glyph, which means that if your first font doesn't have
             a 0 glyph you go down the list and trigger a download for
             the next font on the list
  TabAtkins: So I agree that that's unfortunate
  TabAtkins: One objection is that if zero is defined _and_ being used,
             might as well use it
  TabAtkins: This brings in potentially stateful behavior. Whether or
             not the ch uses it depends on whether the dom contains a
             0, or a user types it, etc
  TabAtkins: So options are: (1) no change, ch triggers downloads
  TabAtkins: (2) always rely on first available font
  TabAtkins: (3) look at 0 if there, and accept it's a stateful behavior

  chris: I think there's a (4), which is switch from the 0 glyph for
  TabAtkins: Does .notdef has a reasonable char?
  chris: it's the tofu
  <dbaron> (or with font-variant-numeric: tabular-nums)
  fantasai: We chose 0 because in monospace we want the pitch of the
            font, and in a proportional font digits are usually
  fantasai: so it fullfills all our these requirements
  fantasai: Switching to .notdef would be a degradation for most uses
            of ch
  fantasai: so I think it's a bad idea
  <jfkthame> fantasai++
  fantasai: Relying on only first available font is problematic because
            often there's a stack where you're mixing latin/cjk fonts,
            so I don't think it's a good idea either
  fantasai: I have no problem with (3) because I think it's going to be
            very unusual
  fantasai: to have a font that doesn't have a 0, and some stack font
            has a zero and doesn't get loaded until later
  fantasai: European digits are used in pretty much every writing system
  fantasai: and chances are the font that has the zero is going to load
  fantasai: so I think the concerns that jfkthame has about triggering
            a reflow when someone types will be very rare
  fantasai: and the other options degrade the ch units

  florian: I think where the fonts at the top of the stack doesn't have
           0 is reasonably typical
  florian: and you want the font with the actual zero
  florian: Stack with latin first, japanese there, without the digits
           seems really unusual
  florian: One way you could workaround it is using the first avail
           font is that first avail font is dependent on the space glyph
  florian: so you could remove the space from the first font down the
  florian: I don't think using the first avail font will buy us anything

  dbaron: I wonder if the argument that (3) is not a big deal is
          because it happens really rarely doesn't apply to (1)
  astearns: Yeah, the lack of the glyph is really rare, and having a
            font that hasn't downloaded yet would be even more rare
  iank: Can you clarify?
  astearns: The most common case for lacking of 0 glyph is subsetting,
            and you do that so that you can use that font and the rest
            of the stack to render content
  astearns: so it's common for that font to be used by the content
  dbaron: Other thought is about impl complexity
  dbaron: and that depends on what the rules for (1) and (3) actually
  dbaron: I think (3) requires that if you _do_ download the font you
          update the ch units
  dbaron: which also applies to (1) because ch units is what triggered
          the download
  dbaron: so I think the only difference in implementation between (1)
          and (3) is whether the download is actually triggered
  TabAtkins: that's correct
  <iank> don't we have the complexity that fonts can be partially
         downloaded in the future?

  emilio: Even though 3 is very rare, I think I'd rather do 1
  emilio: When it happens, it's just terrible, if you have anything
          sized with ch it shifts when you type a character, that's
  emilio: I'd much rather do 1, I think
  emilio: 2 I wouldn't be opposed to, but I think fantasai's arguments
          are compelling
  <dbaron> I agree that (1) (current behavior) is the correct thing.
  TabAtkins: If we're trying to go for 1, I wouldn't be comfortable
             resolving without Myles around, since he was opposed

  florian: This is not unique to ch, we have same problem with ex units
  florian: if you want example that depends on x height of the first
           avail font which is the first one that contains the space
  florian: so if the first one doesn't contain the space you do need to
           trigger the download
  florian: Unless we want to redefine all font units to not depend on
  florian: I think we can't escape this problem entirely anyways
  florian: and giving up on font units doesn't sound like a good idea
  dbaron: not the em unit, but ex, ch, ic, etc.
  florian: So we need one more person to resolve on (1)

  iank: Isn't there a feature to allow fonts to be partially downloaded?
  astearns: Yeah so that would make it more common not to have a 0
  chris: Related, is there anything on CSS that assumes that fonts are
         completely downloaded?
  TabAtkins: Yeah, css-font-loading has a boolean loaded
  chris: Yeah, we need to talk about that
  fantasai: tri-state?
  dbaron: I think I have memories of working with jdagget on the font
          downloading code when ex units are used

  astearns: Seems on this issue we're at an impasse?
  florian: It seems like consensus is towards (1)
  chris: Though myles doesn't like it
  astearns: I think I agree with myles
  astearns: I want to avoid the case where someone has set up their
            fonts so that multiple downloads are triggered just to find
            a character where we could return another value
  astearns: and update when the download occurs
  florian: How's different with ex units and space?
  astearns: Agreed that it's not specific to ch but ch is more common
            and this is more likely to happen
  jfkthame: And arguably it can be avoided by changing the font to
            contain a 0
  astearns: I think this should be an exceedingly rare case but I think
            we should avoid the download
  jfkthame: Because of the rarity I think we should have the correct
            behavior. Having an emoji font at the beginning of the font
            list is not that rare but not getting the ch unit right
            there seems very unfortunate
  <TabAtkins> And thus, that rules out #2

  dbaron: One counterpoint here is that part of what makes this
          condition extra rare is the "and the font doesn't get
          downloaded for anything else". If the ch unit triggers the
          download, it's likely the first thing to download the font
  dbaron: and it might be that the benefit that we get from downloading
          the font earlier is bigger than the issue of triggering an
          unlikely download
  astearns: Say you have a font stacks that has a "my ampersand font",
            "my emoji font" (unused), and "my content font"
  dbaron: and the emoji font does have a 0
  dbaron: so you download the emoji font _and_ your ch unit doesn't
          match what your content actually uses
  dbaron: but if we do (3) then emoji gets used and your ch unit changes
  emilio: Point dbaron was making was if we do 3, then emoji gets used,
          and your ch unit changes
  astearns: In the scenario of (3) the content font would use the right
            ch unit (from the content font, when it loads content), but
            then if you use emoji or a 0 your ch unit changes
  fantasai: I don't think that's going to be a common case
  astearns: Yeah this are all really uncommon things
  astearns: but I agree with myles that prioritizing reducing downloads
            over layout changes is the right call
  fantasai: We can also make it up to the UA
  fantasai: make triggering downloads not required

  florian: We already have the language "if not practical, use half
           an em"
  emilio: But this wouldn't change to half an em
  emilio: it would switch to a font lower in the stack
  emilio: I don't think that the cases that Alan and Myles argued for,
          I'm with dbaron that actually triggering the download for ch
          unit is more likely to help performance than cause problems
  emilio: because by the time you get to layout the text, the font may
          already be there
  emilio: Otherwise you need to do more layout work, takes up all the
          ch units
  emilio: and likely also trigger the download by the time you et to
          the content of the website
  emilio: so I think doing 1 is the right thing
  emilio: and also the more sensible thing
  <jfkthame> Agree with emilio
  fantasai: So... strawpoll?
  TabAtkins: Pick up in two weeks with myles on the call
  TabAtkins: myles was very strongly against (1)
  TabAtkins: so don't want to resolve without him

<br size=1h>

Visual viewport units
  scribe: fantasai
  scribe's scribe: TabAtkins
  github: https://github.com/w3c/csswg-drafts/issues/7194

  fantasai: I think we need someone from WebKit in this discussion
  fantasai: WebKit does all kinds of fun and interesting things with
            the viewport on mobile
  fantasai: Do we know if they'll be dialing in later today?
  Rossen: I'm happy to defer. Also I would prefer to make progress here
          and now since we have enough people to discuss and come to a
          proposed resolution

  bramus: Recently added viewport-relative units
  bramus: lv*/dv*/sv*
  bramus: Suggestion is to add new units for the visual viewport
          units vv*
  bramus: to reflect the width/height of the visual viewport
  bramus: for clear understanding this is the part you see on screen
  bramus: When you pinch zoom, this becomes a viewport on top of the
  bramus: so this is a sub-viewport of the others, and it describes the
          part that you see

  flackr: I think David and Bramus pointed out that if we had such
          units, it would cause layout changes while you zoom
  flackr: which is disruptive and also performance problems
  flackr: The fundamental use case seems to be positioning around a
          virtual keyboard
  flackr: so we have some alternate proposals for positioning things
          relative to the edge of the keyboard
  flackr: see https://github.com/w3c/csswg-drafts/issues/7475

  fantasai: I think Robert's point that pinch-zoom isn't supposed to
            make layout changes (since you're trying to see something
            more clearly that's already laid out) is a really important
  fantasai: so we can't do this, but we can try to address the concerns
            another way
  <emilio> +1 from me too fwiw
  <TabAtkins> +1 from me too on that

  bramus: The use case for visual viewport units is if the author wants
          to have an element that perfectly fits that size
  bramus: simply a use case for an element sized to fit within the
          space left by the keyboard
  Rossen: Any reason why can't use the viewport offsets, that were
          proposed and are in css-env?
  Rossen: We had an elaborate proposal for how to address these various
  bramus: Are you talking about pageLeft/pageTop and offsetLeft/
  Rossen: No
  Rossen: I'll take a second to find the actual issue

  fantasai: I think pinch-zoom and presence of keyboard are two very
            different things
  fantasai: keyboard-shifting makes sense to address, pinch-zoom makes
            sense to specifically *not* address
  fantasai: agree we commonly need to accommodate the keyboard somehow
            and should look into it
  fantasai: but not pinch zoom
  bramus: Should we discuss the issue flackr linked to?
  fantasai: Do we want to take a resolution to not add units that
            respond to pinch-zoom?
  <dbaron> +1
  Rossen: Any objections?

  RESOLVED: Not adding units that trigger layout changes based on

CSS Positioning

Interpreting viewport-positioned (fixed, sticky) elements wrt virtual
  github: https://github.com/w3c/csswg-drafts/issues/7475

  flackr: [presents the issue]
  flackr: Developers want a way to position content that stays in view
          above a virtual keyboard as it slides into place
  flackr: on iOS and ChromeOS this doesn't work today because the
          virtual keyboard that slides into place changes the visual
          viewport but not the layout viewport
  flackr: You can seen an example here
  flackr: the header/footer are clipped and slightly out of view
  flackr: Behavior on Android today is that we resize the page
  flackr: but this is something that we would like to not do

  flackr: Just that there has been strong demand for this use case
  flackr: there has been a prior suggestion to have a position called
  flackr: My understanding of how it works is that device-fixed content
          is outside of pinch-zoom
  flackr: and effectively part of the visual viewport
  flackr: What we dislike about this is that it's not accessible
  flackr: because you can't pinch-zoom this content
  flackr: One alternative is scaling the content with pinch-zoom
  flackr: but then such content starts massively intruding on the
          visual viewport
  <iank> its also quite common for the whole page/app to be within a
         position:fixed element.

  flackr: So what we'd like to propose doing
  flackr: is defining a viewport that just excludes the virtual keyboard
  flackr: but is different from the layout viewport
  flackr: so we don't have to do a global reflow when the virtual
          keyboard shows
  flackr: This keeps your headers and footers in position
  flackr: you can still zoom around
  flackr: This is pretty similar to the effect on android right now
          with the exception of not changing the actual content layout
  flackr: so we think that it should be Web-compatible for the way that
          sites exist
  flackr: Unsure about iOS
  flackr: I think bramus prefers to move towards iOS behavior

  bramus: In general, of all these proposals, 5th is what Robert is
  bramus: and I'm in favor
  bramus: but I'm not in favor of changing how current position:fixed
  bramus: To counter that, I was thinking of extension to position:fixed
  bramus: where you can specify which viewport you are targeting
  bramus: So default is fixed against the layout viewport
  bramus: but you would also have options to lay out against the visual
  bramus: so that when keyboard is shown ....
  bramus: Third option is position fixed fixed, positioned against the
          unzoomed visual viewport
  bramus: which is what robert described as option 5
  flackr: That's developer opting into either 5 or 4
  bramus: The main reason I'm thinking along that line is that we
          wouldn't suddenly change something depending on which
          platform you're on
  bramus: but main advantage to extension to position: fixed syntax is
          that you can feature-detect
  iank: What's the behavior on Android today?
  bramus: What we do right now on Anrdoid is that the layout viewport
          gets resized when you show a virtual keyboard
  bramus: [demo on screen]
  iank: There's a difference also between position:absolute into ICB vs
  iank: What's the difference there again?
  flackr: position:fixed lays out against the ??? viewport

  fantasai: One problem I've often encountered is the headers and
            footers respond to the position of the keyboard, and I'm
            trying to type into something and I can't see it anymore,
            because there's not enough space left
  fantasai: I'd like for us to not have this problem happen by default
  fantasai: I think visual viewport isn't what we're targeting; again
            pinch-zoom must not be responded to
  <flackr> +1
  fantasai: What we want is remaining space after we remove virtual
  bramus: Rob has been using 'unzoomed visual viewport'
  flackr: Suggested calling it fixed viewport

  fantasai: Hard not having webkit here, but I recall someone explaining
            two ways to handle virtual keyboard
  fantasai: one the keyboard takes up space, another it floats over the
  fantasai: IIRC WebKit follows the floating model
  fantasai: so the way keyboard interacts is probably affected by that
  fantasai: I think having a special 'fixed viewport' for when you want
            to attach something to the keyboard or remaining space is
            reasonable, but I don't think it should be default
  flackr: The first behavior I demoed, keyboard floating overtop
          content, is iOS keyboard
  flackr: It does shrink visual viewport but otherwise doesn't affect
  flackr: Option 5 is the same, except you have a viewport that is
          remaining space
  bramus: And its sizing not affected by pinch zoom

  Rossen: Generally speaking, 2 main use cases are iterated have to do
          with in-page UI that wants to behave more or less close to
          the way external host UI appears or disappears or behaves
  Rossen: whether this is a keyboard or navbar or search bar
  Rossen: These various permutations are places we want to target
  Rossen: and to push the use cases a little further
  Rossen: As the UI animates in and out, you want to make sure that
          your stuff animates smoothly with it

  Rossen: this is where device-fixed ideas came in the past
  Rossen: We had a prefixed implementation of this back in the Edge
          platform where we used position:fixed for UI in PWAs and web
  Rossen: in windows
  Rossen: That worked pretty well, but it had the flaw pointed out that
          they don't zoom in and out with the page
  Rossen: which is exactly what you want, because you're trying to
          behave closer to the way this native UI behaves
  Rossen: Pushing things slightly further, we proposed at some point as
          part of a larger proposal
  Rossen: a different way of dealing with this which was to expose an
          environment variable for where the folds are, the top or the
          bottom folds of the device
  Rossen: I recall a discussion in IIRC Coruña that was extending this
  Rossen: maybe it was presented by jensimmons at the time
  <Rossen> https://github.com/w3c/csswg-drafts/issues/4736
  Rossen: That proposal to me was the one that was solving a lot of
          what was being described here
  Rossen: My question is, there has been a lot of work and thinking
          happening here over past 3-4 years
  Rossen: and yet, I'm surprised we're going back to trying to reinvent
  Rossen: Rather than collecting all of the thinking and getting a path
  Rossen: Rob or Bramus, was this approach considered or considered and
          not deemed appropriate or...? what happened?

  flackr: In WICG there's an overlays flag
  flackr: you get an environment variable for the size of the keyboard
  flackr: the developer is picking up the complexity of where the
          keyboard should be
  flackr: Up to them to do the right thing in response to keyboard
  Rossen: That seems another permutation of what we're discussing
  flackr: That is something shipping in Chrome but not any other browser
  flackr: but has complexities because, e.g. you can't scroll to the
          bottom of the page
  flackr: because the keyboard is not considered in your page layout
          at all
  flackr: unless you look to see, how much of the page is my keyboard
  bramus: it also doesn't resize the visual viewport
  flackr: That's a bug

  Rossen: I think we should also consider the other discussion of some
          of the environment variables and how they play
  Rossen: desire to account for scrollbar etc.
  flackr: I have considered some of this, and the initial thinking was
          that it is complex to do the right thing
  flackr: to take all of this into account as a developer
  flackr: We wanted to have an easy thing for devs to use, to handle
          most of the use cases

  Rossen: Every time we want to expose a new unit, that's a last step
  fantasai: We already rejected that
  fantasai: That's not the discussion here

  flackr: What's being proposed here is either new positioning scheme
          or re-intepreting 'position: sticky'
  fantasai: Sticky?
  flackr: We would need to also address sticky, ensure those are still
          in view
  fantasai: I understand wanting that to work... but also... I see so
            many pages that assume there'll be enough space left and
            there isn't space to see what I'm typing into

  Rossen: This is why my preference is for this environmental awareness
          is better expressed in environment variables which you can
          add to your calc() expressions
  Rossen: and then can improve UI clutter depending on how much space
          you have left
  Rossen: With position, you have to work backwards to see how large it
          lays out, and then if you don't like it go back and remove it
  Rossen: much heavier option
  <flackr> Something like position: fixed; bottom:
           env(keyboard-height); ?
  Rossen: Would much rather do a conditional on a calc() expression and
          do everything pre-layout
  Rossen: would prefer to do that pre-layout to decide if element
          continues to be there or not
  Rossen: For example, but can do more than that?
  fantasai: Curious what Rossen means by "do more"
  fantasai: but also, wrt that example, we would want insets from each
            edge of the screen, similar to the safe-area insets
  Rossen: What you just described. Need all 4 sides
  flackr: One complication with that
  flackr: right now adding keyboard inset to the bottom work, but I pan
          down it's at layout viewport plus keyboard height
  bramus: If something is position: fixed; bottom: keyboard-height, it
          would obscure ???
  bramus: because you aren't taking the offset of the visual viewport
          measured against the layout viewport into account
  Rossen: Not if we are exposing the insets env values

  iank: One quick thing, rob, I'm assuming that any proposal
  iank: we're going to be compat-constrained on Android pretty heavily
  iank: because people are relying heavily on our current behavior
  flackr: We have a lot of interop differences, e.g. iOS vs Android
  iank: Yes, but people know this and have written code to make it work
        on each platform
  flackr: I suspect that's true
  iank: I just wanted to make one thing clear, we're in a very sucky
        position here
  iank: but I don't think that Android or Android webview would be able
        to change behavior here
  iank: same with iOS

  emilio: At a glance, from my phone, ?? behaves like Chrome and Firefox
  emilio: resizes and fixes stuff
  emilio: The problem with iOS behavior is can you even see something
          at the bottom of the page?
  flackr: When you pan, you're moving the visual viewport and can
          scroll to the bottom of the page
  iank: I think it's still true that there are various tricks people do
        to get it to autoscroll down into that position
  flackr: When you focus an input, it scrolls into view, and that moves
          the visual viewport
  iank: But people exploit various tricks on iOS to get the visual
        viewport to scroll to the end of the layout viewport
  bramus: Tricks I've seen people use is to steer away from the
          behavior where the browser automatically tires to center the
          input into the visual viewport
  flackr: The reason you can get to the bottom is the browser knows the
          size of the keyboard and shrinks the visual viewport by that
          amount so you can scroll that much extra
  emilio: Do stuff like ??? on iOS, on the keyboard, presumably their
          inputs fix to the top of the keyboard right?
  emilio: like Anrdoid is doing right now

  emilio: On one hand I get that it's nice to not resize the layout
  emilio: but something like either your proposal, which is fine, or
          current android/chrome proposal, seems more towards what
          authors want
  emilio: When is the iOS behavior preferable right now?
  emilio: when you have iOS app, if it behaves like Android
  <flackr> +1
  Rossen: You have to do all kinds of funky UA detection stuff
  flackr: Native apps behave like [missed]
  emilio: They behave like Chrome/Firefox
  flackr: Option 5 was designed to be more like native app behavior

  bramus: What I like about proposal is that it allows authors to have
          both behaviors
  bramus: so if author wants bottom bar not affected by showing
          keyboard, can get that
  bramus: Should they want android behavior, authors can also retain
          the existing behavior by doing feature detection
  bramus: but would require landing both changes on Android at the same
  bramus: so authors can choose to have something at the bottom bottom,
          or above the on-screen keyboard
  <iank> does the proposal allow Android & iOS to keep the current
         default behaviour?
  iank: Does someone have an existing PWA, we're not changing default
  bramus: Twitter app
  flackr: What are you proposing the default is?
  bramus: Default would be to have position:fixed as before, lay out
          items against the outer viewport
  bramus: That would be the iOS behavior
  iank: We can't do that

  flackr: bramus brought about customizing behavior
  flackr: The virtual keyboard overlays content behavior allows
          complete customization of the behavior
  flackr: if you're a site that wants to customize the behavior, you
          can do that
  flackr: this is more about having sensible defaults that work well

  Rossen: So, let's figure out some next steps
  Rossen: Most of the conversation seems to be circling around the
          option 5 that you proposed
  Rossen: We can record that this is the current preferred method

  fantasai: bramus was suggesting there be various syntactic ways of
            opting into different behaviors
  fantasai: I think this is something that, if we want to add it, it
            should be an independently cascade property from position
  fantasai: likely you'll think about how your stuff adapts at a
            different level from how it's laid out
  fantasai: so it should be a different prop
  fantasai: position:fixed, and a "fixed-to:whatever" prop

  Rossen: Do we need to take any resolution on these proposals?
  flackr: We would like to get more feedback
  Rossen: seems we've clearly indicated favorable options, should be
          easier to page in next time
  <fantasai> I also wonder if we want to do this *and* have the
             environment variables
Received on Wednesday, 31 August 2022 11:03:17 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:20 UTC