- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Aug 2022 07:02:36 -0400
- 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
keyboard
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
===== FULL MEETING MINUTES ======
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
point
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
line-height:initial
<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
fine.
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
control
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
matter
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
line-height
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
stylesheets
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,
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/menu_list_inner_element.cc;l=37-45;drc=04861b524177edda323dc6c37ad58e9bf1e85c12
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
browsers
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
.notdef
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
monospace
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
list
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
are
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
terrible
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
fonts...
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
canvas
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
point
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
sizes
bramus: Are you talking about pageLeft/pageTop and offsetLeft/
offsetTop?
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
pinch-zoom
CSS Positioning
===============
Interpreting viewport-positioned (fixed, sticky) elements wrt virtual
keyboard
---------------------------------------------------------------------
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
device-fixed
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
size
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
suggesting
bramus: and I'm in favor
bramus: but I'm not in favor of changing how current position:fixed
works
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
viewport
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
position:fixed
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
keyboard
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
content
fantasai: IIRC WebKit follows the floating model
fantasai: so the way keyboard interacts is probably affected by that
choice
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
anything
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
apps
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
further
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
this
Rossen: Rather than collecting all of the thinking and getting a path
forward
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
showing
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
obscuring
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
viewport
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
time
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
behavior?
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