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