W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-22 Part II: CSS Align, Scroll Snap [css-align] [css-scroll-snap]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Feb 2020 19:51:13 -0500
Message-ID: <CADhPm3u4tZyOJJvFSykrrbWbQOQ042Z==k5BoN694nPnAcHQfA@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 Align
---------

  - fantasai will draft a PR for Issue #3611 (Special case for
      inline-block+scroll-container elements needs to cover inline
      blocks that **contain** scroll containers) saying that a
      inline-block is a scroll container has no baseline and therefore
      will follow the existing rules to synthesize one. Once the group
      has reviewed the PR a call will be made for resolution.
  - RESOLVED: Keep the spec text about auto and stretching that aligns
              with Chromium behavior, but add some clarification.
              (Issue #4525: Does stretch work when width/height only
              behaves as auto?)
  - RESOLVED: Accept the text in current ED and open bugs on browsers
              to implement. (Issue #4659: Center alignment can be
              improved)
  - RESOLVED: Take the legacy and baseline keywords of CSS Alignment
              L3 and move them to L4 (Issue #4660: Punt baseline
              alignment to L4)

Scroll Snap
-----------

  - RESOLVED: Define what happens if you have multiple elements that
              could satisfy the scroll snapping re-snap situation and
              there is one that is focused or targeted. Otherwise
              leave it UA defined. (Issue #4651: Snapping on both axes
              allows re-snap after layout to choose inconsistent snap
              targets)
  - RESOLVED: Require smooth scrolling behavior when there is a new
              snap, but let UA decide when it's re-snapping to the
              same element. (Issue #4609: Re-Snapping after layout
              with animations)
  - RESOLVED: No change to scroll-snap-type, but contain:layout must
              trap snaps. (Issue #4496: Snap area trapping behavior of
              non scrollable elements)
  - RESOLVED: Use visual viewport for snapping and layout viewport for
              scroll-padding percentages. (Issue #4393: What's the
              optimal viewing rect on the root scroller?)
  - RESOLVED: Keep the previous resolution to snap to the container's
              start edge, except when the element is larger than the
              snap port, in which case we use the start edge of the
              element. (Issue #3815: Clarify which writing-mode is
              used for scroll-snap-align, scroll container or snap
              position element?)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/galicia-2020

Scribe: heycam

Summer Meeting
==============

  astearns: Do we have a date set? has Google reserved rooms?
  Rossen: There's a date in the wiki
  <tantek> https://wiki.csswg.org/planning#upcoming-meetings
  TabAtkins: Majid was organizing this
  astearns: Let's ping him, then come back later
  <tantek> my only request on meeting dates is to avoid July 27 (day
           after SF Marathon)
  <tantek> I can add it to the wiki :P

CSS Align
=========

Aligning inline blocks that **contain** scroll containers
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3611

  TabAtkins: Not sure if this needs discussion, dholbert agreed
  TabAtkins: Questions from dholbert was about baselines for
             inline-blocks in certain cases
  TabAtkins: The baseline export section, block containers, it says
             for legacy reasons [ ... ] the baseline is synthesized
             from the margin box
  TabAtkins: dholbert found this doesn't cover what browsers do today
  TabAtkins: There are some cases where it does look inside to
             elements for a baseline
  TabAtkins: We found a fix
  TabAtkins: Rather than testing for inline block being a scroll
             container, change it to if it has a child that is a
             scroll container
  iank: Should be any descendant
  astearns: That's not what's in the issue though
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7695

  TabAtkins: If the inline block is a scroll container, it works
             properly
  TabAtkins: but dholbert found if it contains a scroll container and
             nothing else, the only child, you still shouldn't look at
             that child for baseline info, just synthesize
  TabAtkins: We discovered that the condition is different -- some
             scrollable blocks still do influence the baseline
  fantasai: It should be the first in-flow item [...]
  dbaron: Only if the scroll container is block level
  TabAtkins: Scrollable flex boxes that are child of an inline block
             still give their baseline info
  TabAtkins: it's just block containers that hide themselves
  TabAtkins: inline blocks and blocks
  emilio: In Gecko, the baseline of a scrolling box is synthesized
          from the margin box if the scrolled thing is block level, or
          you have contain: layout
  emilio: so I think there may be an easier way to define this
  emilio: The scroll box synthesizing the baseline from the margin
          box, not by looking inside

  dbaron: Is your proposal the thing in the "13 days ago" comment:
          https://github.com/w3c/csswg-drafts/issues/3611#issuecomment-572756316
  TabAtkins: Yes
  dbaron: My understanding is that this fixes it because it's fixing
          the recursive invocation of the same alg
  dbaron: think this makes sense
  iank: Still applies for any arbitrary child?
  iank: I think this special scroll behavior is only executed in the
        inline block behavior
  iank: looking at the last baseline
  TabAtkins: If anyone has any possible complications, please comment
             on the issue

  fantasai: I think the change we're planning to make would be in this
            section
  <fantasai> https://drafts.csswg.org/css-align-3/#baseline-export
  <fantasai> "However, for legacy reasons, if an inline-block is a
             scroll container or contains no in-flow line boxes, its
             first and last baseline sets are synthesized from its
             margin box."
  fantasai: We'd say it has no baseline set
  fantasai: and that would trigger the appropriate behavior
  iank: If you have multiple children
  iank: two children, one scrollable container, then some text, you'd
        pick up the baseline from the text?
  iank: If it didn't have a baseline set?
  fantasai: We're requesting the baseline of a box. If it says it
            doesn't have one, it'll synthesize
  iank: There's a subtle difference between synthesizing a baseline
        for a box vs something like providing a baseline
  iank: Some things like tables inside of an atomic inline context,
        they don't synthesize a baseline and they get skipped for this
        calculation
  iank: but scrollable containers don't get skipped
  fantasai: Each formatting context says "this is how I find my
            baseline to export it out", and table will say my exported
            baseline is the first row or whatever
  fantasai: but for block containers, it'll look at the first
            baseline, skipping tables etc., the next element that's
            there and ask it
  iank: The scrollable container the baseline it exports out is the
        block-end offset
  iank: When we enter into an atomic inline block, we set a bit on
        input saying "I need the last baseline since I'm in an atomic
        inline block"
  iank: and that triggers this special behavior
  iank: It propagates through block level block containers
  fantasai: Going forward we'll have an option to choose first or last
            baseline
  iank: That's fine

  fantasai: I'll make a PR with some proposed text and we can go over
            it later
  astearns: Since this is a spec change should help match reality, can
            it come with tests?
  TabAtkins: Yes

Does stretch work when width/height only behaves as auto?
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4525

  oriol: This is about grid items. The default alignment is stretch
  oriol: This is supposed to stretch an element to cover the container
  oriol: but only if the computed width computes to auto
  oriol: The spec has some confusion about computing to auto
  oriol: Could mean "behaves" as auto
  oriol: Firefox thinks this is the case, and instead of checking the
         computed value being auto, it checks whether it behaves as
         auto
  oriol: e.g. if you set the height to max-content it behaves as auto,
         in Firefox it stretches, but in Chromium it doesn't
  oriol: The question is whether if the width/height is set to a value
         that behaves as auto but isn't auto itself, does this stretch?
  fantasai: I think the author did not want automatic behavior if set
            to a value other than 'auto'
  oriol: In the most common behavior, automatic behavior is sizing to
         the content
  oriol: In the context of grid and flex, auto isn't equivalent to that
  oriol: If the author has set it to a value that's not auto, we
         shouldn't automatically stretch
  oriol: I think the spec is correct to rely on computing to auto, so
         we should align on Chromium's behavior
  TabAtkins: mats also says that sounds reasonable
  emilio: It's a bit weird that max-content behaves as auto for
          some things but not others
  <tantek> is there a test case for Chromium's behavior?
  <rego> tantek:
https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23grid%20%7B%0A%20%20display%3A%20grid%3B%0A%20%20width%3A%20100px%3B%0A%20%20height%3A%20100px%3B%0A%20%20grid-template%3A%20100%25%20%2F%20100%25%3B%0A%20%20background%3A%20yellow%3B%0A%7D%0A%23item%20%7B%0A%20%20height%3A%20max-content%3B%0A%20%20align-self%3A%20stretch%3B%0A%20%20background%3A%20cyan%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22grid%22%3E%0A%20%20%3Cdiv%20id%3D%22item%22%3EText%3C%2Fdiv%3E%0A%3C%2Fdiv%3E

  RESOLVED: Keep the spec text about auto and stretching that aligns
            with Chromium behavior, but add some clarification.

  astearns: Let's get that test case into WPT

Center alignment can be improved
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4659

  <TabAtkins> https://drafts.csswg.org/css-align/#abspos-sizing
  TabAtkins: The diagram shows how alignment affects the available
             space for sizing static positioned abspos elements
  TabAtkins: You have the abspos containing block
  TabAtkins: you have the parent of the abspos (the static pos
             containing block)
  TabAtkins: and you have the abs pos child
  TabAtkins: It's statically positioned in the horizontal axis
  TabAtkins: We now look at justify-self for alignment
  TabAtkins: Historically we had one rule to do this, based on
             direction
  TabAtkins: here we're letting you specify that explicitly
  TabAtkins: If start aligned, it does what you expect
  TabAtkins: the space to align into starts on the start edge where
             the static position is, and goes to the end of the abspos
             containing block
  TabAtkins: It sits in the same spot, but grows to where 0 would be
  TabAtkins: If you're end, you do the opposite, growing to where
             left:0 would give you
  fantasai: (This is the behavior for RTL text)
  [astearns iank illustrates Tab's narrative in real time]
  TabAtkins: How do you do center?
  TabAtkins: Previously the spec said you use this box [points to
             blackboard]
  TabAtkins: You can't get bigger than the static containing block,
             which is weird because the other alignments can
  TabAtkins: Ian's suggestion is to let it grow from both sides until
             one side would hit the edge of the abspos containing block
  TabAtkins: It's centered in the expected space, but gets as large as
             it can

  iank: This is EdgeHTML's behavior
  iank: We'll have this when we pick up our new flex impl
  iank: We've added some tentative tests
  TabAtkins: Nobody currently center aligns according to the current
             spec
  TabAtkins: I've edited this into the spec
  dbaron: This is the width you end up with auto width?
  TabAtkins: If you have enough content
  <fremy> lgtm
  fantasai: Fun side effect, this makes it possible to interpolate
            between all three values
  fantasai: since it's between the other two values

  iank: This fell out because we were adding static center positions
        in our new arch, and this was the obvious thing that fell out
  iank: was relatively easy for us to do
  dbaron: I didn't realize we implemented this section of the spec at
          all, I'm ok with this
  cbiesinger: We only implement this for flex boxes?
  iank: We get the available size more wrong
  cbiesinger: But we only do this if the parent is a flex box?
  iank: Yes
  iank: Only applies in implementations with flex boxes
  dbaron: Then it makes more sense to me that we implement it
  dbaron: because in theory this should be implemented for blocks too

  dbaron: As I've mentioned before, I'm worried we'll be unable to
          implement this for block
  heycam: Is Chrome implementing block alignment as part of your
          rewrite?
  iank: Not currently. But the new arch does make it easier to
        implement
  astearns: Can you get into this situation with abs positioning as
            well?
  iank: I don't think so
  astearns: Given this was not well specified before, can you open
            bugs on impls to match the current text?
  TabAtkins: Sure
  rego: So it applies in grid too?
  TabAtkins: In all places that use this text, so flexbox, grid, and
             theoretically block

  RESOLVED: Accept the text in current ED and open bugs on browsers to
            implement.

  cbiesinger: Can we add WPT tests?
  iank: I already have

Punt baseline alignment to L4
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4660

  TabAtkins: We want to take Alignment to CR and further
  TabAtkins: It's a fairly stable spec, tiny issues solved, except for
             baseline alignment
  TabAtkins: Propose taking baseline alignment stuff out and moving it
             to L4
  TabAtkins: L3 will contain everything but that
  TabAtkins: then pursue L3 CR
  fantasai: I think it's a bit odd since baseline was a very early
            feature in flexbox
  fantasai: and it is already implemented
  fantasai: but I won't object
  fantasai: There's also an issue about baseline alignment vs intrinsic
            sizing not being adequately explained, prevents taking the
            current spec to CR; havn't figured out how to fix

  florian: So remove the keyword from L3?
  TabAtkins: Yes
  TabAtkins: I don't see why we need to say anything about it in L3 if
             we also publish L4
  fantasai: Alternative is just take the whole thing to CR despite
            these issues
  <fantasai> Main issue we're holding on is
             https://github.com/w3c/csswg-drafts/issues/1409
  <fantasai> Then there's also that the baseline alignment sections
             just seem to generate the majority of new issues
  TabAtkins: Flexbox L2 won't have the justify and align properties
  florian: If flexbox depends on L4, it's no worse than depending on
           the combined spec

  astearns: What do we gain from a L3 CR?
  TabAtkins: Process
  astearns: And highlighting issues with flexbox relying on unresolved
            things?
  florian: It's unfortunate but we have this problem
  fantasai: Most incoming issues are around baseline alignment
  fantasai: the other issue is the one dbaron raised
  astearns: Slightly more in favor of pushing out a CR of L3
  astearns: since it replaces some parts of CSS2
  fantasai: No, this is just replacing a few slivers of Chapter 10
  <fantasai> a few sentences
  <fantasai> here and there
  <tantek> any incremental replacement of CSS2 is a good thing
  TabAtkins: But I would like to indicate that the rest of this is
             stable

  fantasai: I would also suggest punting the legacy keyword out of L3
  fantasai: because it's defined but nobody's interested in
            implementing
  fantasai: If nobody's willing to hook this into the HTML features
            it's defined to help, I don't feel like proposing people
            implement it
  TabAtkins: And they won't be doing it until these apply to block
             anyway
  florian: So is it pushed to L4 or At Risk?
  TabAtkins: L4
  TabAtkins: not a stable feature since we have no implementation
             experience
  fantasai: Or even idea of intent to implement

  RESOLVED: Take the legacy and baseline keywords of CSS Alignment L3
            and move them to L4

Scroll Snap
===========

Re-snapping rules given multiple snap targets
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4651

  fantasai: This was an issue raised, there's 2 types of snapping when
            the document's layout changes
  fantasai: One type of snapping is find the element you were snapped
            to, and snap back to it
  fantasai: The other type is try to find something to snap to from
            current scroll position, and snap to it

  fantasai: Sometimes you can have multiple elements that happen to
            snap at the same position
  fantasai: so when you're in a snapped position, it's not clear which
            you should re-snap to
  fantasai: if re-snapping is what you do
  fantasai: The request was to define which element to re-snap to

  fantasai: I suggest leaving it to the UA
  fantasai: but we could suggest if it's the target element or has
            focus, choose that one.
  fantasai: Otherwise I don't have a good idea for a heuristic, and I
            don't want to disallow UAs to have the freedom to track
            which is the one currently snapped to in some smarter
            manner
  astearns: If we're going to have that suggestion, why not specify it?
  fantasai: We can specify the focus/target heuristic, but for cases
            without target/focus, I don't want to specify that
  astearns: I think it would be a good idea if someone would run into
            this issue if developing in a browser and they end up
            relying on the UA's choice

  fantasai: [explains an example with a grid with multiple elements in
            columns, where each column matches the snap position]
  <fantasai> Example is a 5-column grid of elements. We scroll down,
             snapping to each row as we go. The user stops scrolling,
             resizes the page.
  <fantasai> It now has 2 columns
  <fantasai> 5 elements we were snapped to are now distributed across
             3 columns
  <fantasai> which one do we snap to?

  florian: Leaving it open for now doesn't prevent us from coming up
           with a heuristic later, or a new property to specify which
           to re-snap to
  florian: It's like we have an implied "auto" initial value of such a
           future property, where auto is UA dependent

  astearns: Proposal is to define behavior with focused or targeted
            elements in the set of currently snapped to elements

  myles: One piece is whether the browser picks an element and follows
         it, or if the browser should snap to something nearby
  myles: Q2 is if it's picking an element and following it
  fantasai: Spec currently requires that if you're snapped to an
            element, and layout changes, you follow it
  fantasai: Problem is if there are multiple elements at the current
            scroll position
  <fantasai> Similar question to scroll anchoring -- lots of
             heuristics involved, don't think we can specify exactly
  myles: What's the reasoning for following?
  TabAtkins: If you're snapped to it, and you rotate your phone, you
             probably want to follow it
  fantasai: Similar situation to scrolling anchoring, but you have
            more info available, because the snap positions are clearly
            associated to an element.

  heycam: Interactions between scroll anchoring and scroll snapping?
  fantasai: If it's a target, when you scroll to the target, you'll
            snap to it
  fantasai: Similar to scrollIntoView, focus(), these should all
            trigger scroll snapping if it's defined on the element

  heycam: What if one element is focused and the other is the target?
  fantasai: Probably leave it undefined
  fantasai: though focus seems more important than target...

  RESOLVED: Define what happens if you have multiple elements that
            could satisfy the scroll snapping re-snap situation and
            there is one that is focused or targeted. Otherwise leave
            it UA defined.

  <florian> do we define what happens if you're using mandatory
            snapping, and focus/scrollintoview/etc to an element that
            doesn't have a snap position?

Re-Snapping after layout with animations
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4609

  fantasai: Re-Snapping can be triggered in different cases
  fantasai: E.g. if you're snapped to an element, and the layout
            changes
  fantasai: Another one is a new snap position exists, or now you're
            in range of a snap position and you weren't before

  fantasai: Scrolling is sometimes animated, sometimes not
  fantasai: There's a scroll-behavior property that controls
            programmatic scroll animations
  fantasai: Majid is saying that the scroll-behavior should probably
            also control the programmatic scroll behavior that's
            triggered by scroll snapping
  fantasai: and you might want to treat re-snapping to same element
            differently from "not snapped, but not you're going to
            snap"

  fantasai: One proposal is to define that the snapped to a new
            element case be treated scrolling wise as the same as
            scrollIntoView() or focus()
  fantasai: and then therefore define that this should be subject to
            scroll-behavior
  fantasai: The other thing we could do is to allow the UA do something
            different for the re-snap case
  fantasai: but in the case where you weren't snapped before, those
            cases should be animated in the same way scrollIntoView
            animates, and thus be subject to scroll-behavior

  myles: Why standardize this at all? why not say nothing?
  TabAtkins: Because Majid finds that the smooth scrolling behavior
             for the new snap position seems reasonable for the author
             to want to depend on
  TabAtkins: For the same reason scrolling to random things from JS be
             guaranteed smooth
  fantasai: Also clarifies interaction with scroll-behavior

  myles: How about the re-snapping behavior?
  fantasai: I think we want to say something about it to make sure
            it's seen as distinct
  fantasai: We need to distinguish the re-snap case to be UA dependent
            so that scroll-behavior is not required to affect it
  fantasai: Don't feel the need to require not animating in that case,
            but should suggest it's possible
  fantasai: The goal of this re-snapping is to make the user feel that
            the layout changed but I didn't scroll
  fantasai: You don't want to animate to get back to where you were
  myles: I think it depends how much of the viewport space the element
         takes up
  myles: If it's a small element, having most of what the user see
         jump to a different position would look jarring, but if the
         element covers most of the viewport, then jumping makes more
         sense. So would prefer may rather than should
  TabAtkins: That's reasonable
  TabAtkins: as long as we distinguish it so that these cases are
             separate

  <tantek> As a user I may want a more responsive UI and set all the
           scroll behaviors to 'instant'
  <tantek> like I want a way to turn-off cheesy animations

  RESOLVED: Require smooth scrolling behavior (controlled by
            scroll-behavior) when there is a new snap, but let UA
            decide when it's re-snapping to the same element.

Snap area trapping behavior of non scrollable elements
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4496

  fantasai: Snapping is on any descendant, not just children
  fantasai: Currently scroll-snap-type mainly only has an effect on
            a scroll container
  fantasai: but if you set a non-none value on a non-scrolling
            descendant, it has the same affect as on a scroll container
            in that descendant snap areas within that box will no
            longer affect the ancestor scroll container
  fantasai: Majid points out this hasn't been implemented
  fantasai: and that this use case of wanting to trap any of these snap
            areas is already handled by setting overflow to auto or
            hidden
  fantasai: which means we can remove this rule
  fantasai: I'm not convinced on requiring overflow be set to do this
  fantasai: but also we have the contain property, which likes to
            contain things, maybe you want contain layout on it -- and
            you might want contain:layout to trap snap areas
  TabAtkins: Yes it should
  fantasai: If we're implementing the possibility of trapping snap
            areas via contain:layout, seems to make sense we maintain
            the ability to have this independent switch through the
            scroll-snap-type property

  astearns: Adding a value to scroll-snap-type?
  TabAtkins: No, it's just any value other than none
  TabAtkins: The idea would be there's not enough stuff depending on
             this not trapping

  heycam: I kind of find it weird to re-use scroll-snap-type for this
          different meaning
  fantasai: You can think of it as scroll-snap-type always captures
            snaps, just if there's no scrolling there's no other effect
  fantasai: This is already in the spec
  fantasai: We might want to consider re-tagging this issue against
            contain, so that we can make contain:layout do this
            capturing
  TabAtkins: snapturing

  RESOLVED: No change to scroll-snap-type, but contain:layout must
            trap snaps.

  <TabAtkins> an explicit `scroll-snap-type: ignore` could be added
              for this exact case if we really felt like it.

What's the optimal viewing rect on the root scroller?
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4393

  emilio: While working through some scroll anchoring issues
  emilio: you need to decide what rect to anchor stuff to
  emilio: Firefox uses visual viewport, I think Blink uses layout
          viewport
  emilio: both are kind of reasonable
  emilio: but for layout viewport, need to decide the effect of
          scroll-padding etc.
  fantasai: My proposal is to use visual viewport for snapping,
            but that %s on the scroll-padding reference the layout
            viewport
  fantasai: That's where you're likely to block out e.g. fixed content
  TabAtkins: If we snap in the visual viewport, and you bring up the
             keyboard, it has to move?
  jensimmons: It depends
  fantasai: Can leave that to the UA
  TabAtkins: Sounds complicated, but I think that's the best route
  emilio: I think it's pretty reasonable
  iank: Seems like David is fine with this change
  fantasai: Sounds like Blink is doing that
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4393#issuecomment-537844295
  Rossen: Currently using the layout viewport, but if you're zoomed in
          you're not snapped at all
  iank: But sounds like David Bokan is fine to switch to the visual
        viewport?

  RESOLVED: Use visual viewport for snapping and layout viewport for
            scroll-padding percentages.

snap area or snapport writing-mode for snap alignment?
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3815

  fantasai: Already discussed what to do when you have a snapping
            element that has a different writing mode from the scroll
            container
  fantasai: Snap to start edge -- the start edge of element being
            snapped or the scroll container?
  fantasai: My original argument was the writing mode of the scroll
            container, because when you're doing alignment in general,
            we always use the writing mode of the container, so that
            all elements with the same start/end alignment are aligned
            in the same way
  fantasai: Seemed reasonable, consistent to use alignment container's
            writing mode, i.e. snapport's writing mode
  fantasai: but then for snapping it makes a bit less sense
  fantasai: Consider an unusual case, you have a scroll container
            that's ltr
  fantasai: Inside there are a bunch of cards, text has articles in
            various languages
  fantasai: Most are ltr, snapping on start edge will snap on the left
  fantasai: Another is rtl, it'll also snap to the left edge
  fantasai: If they're smaller than the container that seems ok
  fantasai: but if the card is larger than the scroll port, then you'd
            end up snapping to the end of the content as the first
            thing the user sees
  fantasai: but you're trying to snap to the start of the element
  fantasai: So upon reflection it might make sense to use the writing
            mode of the element being snapped to

  Rossen: Only for non-orthogonal?
  fantasai: Similar case for orthogonal flows

  fantasai: The "start" of the content, with current rules, you'll end
            up scrolling to the end of the content
  fantasai: As long as the snap area is smaller than the viewport, it's
            not a problem

  Rossen: What happens in the the opposite case? When the scroll port
          is larger than the item
  fantasai: The behavior should be consistent
  fantasai: but in terms of use cases, when the content is smaller
            than the scrollport, it's not a big usability consideration
            to use the left or right edge; but when content is larger,
            can be a problem to align to the wrong edge

  Rossen: My question is, let's say we have two items
  Rossen: first one is ltr, other is rtl
  Rossen: They're side by side, 1000px wide each, and we have a
          viewport that's only 500px wide
  Rossen: If we're snapping to the start, the first place we snap to
          is box A, which is ltr
  Rossen: The first child
  Rossen: that'll snap to the left
  Rossen: When you snap to the next one, it'll snap all the way to the
          right edge of the rtl element
  Rossen: Say that there are many elements, and these two are still
          side by side, and you're doing a carousel kind of thing
  Rossen: Every element is snapping to the start of the scrollport
  Rossen: Element A is going to snap to its left side
  fantasai: The next one snaps to the right edge of element B
  fantasai: You're snapping the right edge of B to the right edge of
            the scroll container

  fantasai: An important thing to think of is snapping because of focus
            /target, and if you target an entire section and it has a
            different writing mode and you snap to the end of that
            section, that's not good for usability

  [blackboard drawing]
  [general agreement of oddness]
  astearns: Could say you snap to the scroll container's start edge,
            unless the snap element's start edge is not in view, in
            which case you snap to the element's start edge
  florian: Or if the element and scroll port size are the same
  Rossen: It's not terrible
  Rossen: If the item fits entirely in the scroll container, it makes
          more sense to use the writing mode of the scroll container
  Rossen: If the inverse is true, and the items are larger than the
          scroll container, it makes more sense to use the item's
          writing mode
  florian: And at the mid-point it's indistinguishable

  jfkthame: Still seems a bit weird if some are smaller and some that
            are bigger
  Rossen: Would it though?
  Rossen: The invariant here is that every time you snap to a start,
          you'll guarantee you can start reading
  Rossen: so if you have a collection that varies small and large, you
          can always snap to a snap that will guarantee that invariant
  Rossen: Sometimes you will go past what could be considered the
          start item from the scroll container's perspective

  jfkthame: What's troubling me is that for the items that are smaller
            than the container, their start is going to end up in the
            middle
  Rossen: I think this is the solution that guarantees you can start
          reading
  Rossen: It's more important to be able to see the start of the item
          than have the same alignment point
  Rossen: In the inverse case, it seems more appropriate that you snap
          in the direction of the container, so you don't have to jump
  Rossen: that would change the direction of the scroll
  Rossen: Here you're preserving the direction of the scroll, you're
          just keeping that invariant that you can read the start of
          the item
  fantasai: I can take an action to propose some text

  heycam: So if you have this element attached to the scroller
  heycam: and you start narrowing the browser window, it'll start
          attached to one edge, but end up attached to the other edge
  fantasai: Yes, but it is continuous

  RESOLVED: Keep the previous resolution to snap to the container's
            start edge, except when the element is larger than the
            snap port, in which case we use the start edge of the
            element.
Received on Thursday, 13 February 2020 00:52:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC