- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 3 Aug 2020 19:42:11 -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 Grid
--------
- RESOLVED: The auto minimum size is zero for grid items that span
multiple tracks when at least one of those tracks is
flexible. (Issue #4783: Intrinsic contributions for
items spanning flex tracks are not web compatible)
- RESOLVED: When distributing the intrinsic contribution of a grid
item, if it spans flexible tracks, excess size is
distributed to those tracks and not to fixed/auto sized
tracks. (Issue #4783)
- RESOLVED: Accept the edits made to the ED re minimum vs
min-content (and add WPT tests) (Issue #4790: Growth
limits not increased with min-content contributions of
spanning items)
CSS Overflow
------------
- There was interest in exposing pan and zoom functionality through
CSS (Issue #5275: Consider adding new CSS primitive for
per-element panning and zooming (for web maps))
- This is a complex space so it's important to make sure all use
cases have been investigated and there is a proposal that takes
them into account
- Concerns were raised that on the web this wouldn't be used for
maps since people will want their custom solutions. However there
are other use cases such as PDFs that could also use pan and
zoom.
- An additional possible benefit would be standardizing the gestures
for these actions which would be good for accessibility and
interaction from new / unusual devices.
- A possible solution would be to have new generic property that
switches into pan+zoom mode and a gesture-based JS approach
which authors could hook into and make their own approach.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday
Present:
Rossen Atanassov, Microsoft
Tab Atkins-Bittner, Google
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Simon Fraser, Apple
Daniel Holbert, Mozilla
Dael Jackson, Invited Expert
Una Kravets, Google
Peter Linss, Invited Expert
Alison Maher, Microsoft
Myles Maxfield, Apple
Cameron McCormack, Mozilla
Tess O'Connor, Apple
Manuel Rego, Igalia
François REMY, Invited Expert
Devin Rousso, Apple
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Lea Verou, Invited Expert
Scribe: AmeliaBR
Upcoming Meetings
=================
astearns: I don't think there's much housekeeping. TPAC will be
virtual, need to start planning, hopefully more in advance
then for this
TabAtkins: When is TPAC?
fantasai: Late October, but the TPAC week is for breakouts, groups
are encouraged to do F2F not on that week, so TPAC will be
more spread out to make room for time zones.
fantasai: AC meeting also a separate week.
CSS Grid
========
Intrinsic contributions for items spanning flex tracks not web
compatible
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4783#issuecomment-587749012
oriol: This is a web incompatibility issue.
oriol: In the last published version of spec, we weren't taking into
account intrinsic contributions of items that span multiple
tracks, if one of those tracks was flexible.
oriol: This doesn't make much sense. So we changed in ED, but when
I tried to implement the change I had to revert because it
wasn't web compatible.
oriol: My proposal is to alter the draft to keep as much of the new
behavior as possible, but still be web compatible.
oriol: But I found 2 different problems.
Oriol: First, there's a common pattern of 12 columns sized with 1fr.
The intention is that all columns are equal sized & not
overflow. But problem is that 1fr by default has `auto` min
size, which takes intrinsic size into count.
oriol: Right now, you don't see the auto min because most items span
multi-columns. If we changed that so the intrinsic has an
effect, you could make columns uneven or even overflow
container.
oriol: Now, this is partly an author error. You'd get the overflow
if you had items that didn't span multiple columns. Could use
minmax() to make it work, but since 1fr was working, authors
didn't do that.
oriol: So suggestion is that the auto min width of elements is zero
if they span multiple tracks, at least one track is flexible.
oriol: Then in the algorithm, we'd change the auto min width, but
the rest would work out based on that.
oriol: But if someone explicitly said `min-content` for minimum
width, that would work correctly.
oriol: I think this would handle most web compat issues.
oriol: There's an example with code & images in the issue.
<fantasai> +1 to Oriol's proposal
jensimmons: So, right now this is about making things easier for
authors? They *can* do what they want either way, but
this is about making the default better?
oriol: Right now in browsers, you can't use min-content or
max-content for these items. It always behaves as zero. So
the proposal is to support that. It's what the current draft
was trying to do, but the change addresses the compat. Going
back to always being zero isn't very useful.
fantasai: FWIW, tab & I support the proposal.
oriol: Should I cover the other issue, or resolve on this.
PROPOSAL: The auto minimum size is zero for grid items that span
multiple tracks when at least one of those tracks is
flexible.
astearns: Are there any concerns about having a switch based on
spanning multiple tracks.
fantasai: I think that's better than the alternative.
fantasai: The published draft already has a switch based on spanning
multiple tracks. It means we don't consider intrinsic
sizes at all. The existing change to the ED got rid of
that, but it's not compatible by default.
fantasai: Oriol's proposal is that by default you get the current
behavior, but if you specify something explicit that is
used instead.
fantasai: So yes, we have an inconsistency about whether the
intrinsic size is considered, based on spanning multiple
tracks. But we're shifting the inconsistency from the grid
algorithm to the definition of auto min size.
<fremy> fwiw, now that understand the difference between current and
proposed, I support this change
Rossen: But we're still having an inconsistency in auto min size.
The default behavior isn't do the right thing.
fantasai: Yes, but it's do what authors currently expect because of
current implementations.
Rossen: Is compat that bad?
fantasai: Yes.
Rossen: OK, so I guess this is least worst solution.
RESOLVED: The auto minimum size is zero for grid items that span
multiple tracks when at least one of those tracks is
flexible.
oriol: OK, the second problem affected authors who knew about the
problem of using auto minimum in a flexible track, so they
used an explicit minimum of zero, which then causes a
separate problem.
oriol: If you have 2 columns, one sized with minmax, other with 1fr.
One item in auto column only, the other item crosses both.
oriol: Author expects the flex item to fit the item that's only in
that column, but we resolved in 3075 that *all* the flexible
tracks, if they don't have an intrinsic minimum, it would be
spread across all the tracks that an item spans.
oriol: Otherwise, a minimum size on a particular item could cause it
to overflow.
oriol: But generally the element spanning both columns is the larger
one, so this can result in stretching the column & therefore
the other item too much.
oriol: This could have been fixed with the content keywords, but
since setting a minimum of zero was formerly a good way to do
this, that's what they used.
oriol: Proposal is to modify resolution from 3075. If an item spans
flexible tracks, when running track-sizing algorithm, the
intrinsic contribution will only be distributed among the
*flexible* tracks it spans, not the non-flexible ones.
oriol: That would solve this use case. There wouldn't be too much
contribution going to the auto column, all the extra would go
to the flexible one.
oriol: The resolution we just took would still cover the use case we
were trying to solve in the previous issue.
astearns: We never resolved that other issue.
fantasai: But the resolution we just had would address it, with this
one modification.
fantasai: I think there are some subtleties to define in what we
mean by flexible tracks taking up this extra size. E.g.,
depends on whether it has a fixed or intrinsic minimum
size, and whether we're sizing the grid under a min size
constraint.
oriol: Should we do this at all if sizing under a min/max content
constraint?
fantasai: In that situation, we always consider the contents. That's
expected. But I think we still have some errors there were
we consider the max, but not the min. So we do need to
think about those details.
<fantasai> https://drafts.csswg.org/css-grid-1/#algo-flex-tracks
fremy: My impression of this topic is that we had something widely
implemented that we didn't think was well designed, but now
we're making piecemeal changes to try to fix compatibility.
But I'm afraid we're going to get inconsistent implementation
where some browsers make some of these changes but not
others. Reminds me of CSS tables, in a bad way. We're going
to need careful tests to make sure we have consistency.
TabAtkins: Elika & I have been adding tests against the changes
section, so we should catch that quickly.
fantasai: And we can add tests for these changes in next couple
weeks.
astearns: So, you have no concerns about these particular changes,
just about following up with tests?
fremy: Yes.
astearns: fantasai, the other issue you raised about the algorithm
not handling min/ max content, that's a separate issue?
fantasai: yes, we can still go ahead with this.
oriol: PROPOSAL: When distributing the intrinsic contribution of a
grid item, if it spans flexible tracks, excess size is
distributed to those tracks and not to fixed/auto sized
tracks.
Rossen: {Gives an example}
oriol: No. If there are fixed size tracks, that size is subtracted
before distributing extra to the flexible tracks.
Rossen: OK, then I agree. Need to make that clear.
RESOLVED: When distributing the intrinsic contribution of a grid
item, if it spans flexible tracks, excess size is
distributed to those tracks and not to fixed/auto sized
tracks.
astearns: ... and add tests
Growth limits not increased with min-content contributions of spanning
items
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4790#issuecomment-664068575
<fantasai> https://drafts.csswg.org/css-grid-1/#algo-content
fantasai: This will make more sense if I pull up the relevant
section of the spec. ↑
fantasai: There are several sections in how we handle intrinsic
sizes. Minimums first, then maximums. For minimums,
there's auto, min-content, max-content. For maximums,
there's no auto, so min-content then max-content.
fantasai: When we edited the spec recently to add new terminology,
we accidentally said “minimum” when we meant
“min-content”. But when we went to fix that, discovered
had been implemented as written, so need to confirm the
reversion.
fantasai: The current text is rather nonsensical. It's very rare/
weird that min-content would be specified as the maximum
value of your minmax range while not also the minimum.
We should fix it.
astearns: Anyone have actual web compat information measured? Or
should we change & see if we get negative feedback.
oriol: I do know there is no WPT for the bad behavior, although
there is a Chromium internal test.
<fremy> sounds unexpected to me
fantasai: I can't see any reason why anyone would write this code,
with min-content in the max side of a minmax function.
-> minmax(<length>, min-content)
fremy: I don't expect people would do that. We should be able to fix
this.
PROPOSAL: Accept the edits made to the ED re minimum vs min-content
(and add WPT tests)
RESOLVED: Accept the edits made to the ED re minimum vs min-content
(and add WPT tests)
CSS Overflow
============
Scribe: fantasai
CSS primitive for per-element panning and zooming
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5275
AmeliaBR: This has come up with work I've been doing, and zcorpan
was reviewing, on standardizing map viewers
AmeliaBR: A map embed, where you move around the map on the screen
and zoom in / out
AmeliaBR: There's no standard way to describe that behavior in specs
AmeliaBR: But it is a very common pattern, with common interaction
patterns
AmeliaBR: Mouse behaves a certain way, touch behaves a certain wain
AmeliaBR: In addition to map viewers, also common for product photos
on a retail site
AmeliaBR: data visualizations
AmeliaBR: Some things to think about..
AmeliaBR: two different aspects of typical pan+zoom impl
AmeliaBR: One is the UI and interaction patterns
AmeliaBR: how the end-user indicates, by gestures or whatever, where
they want to go and and zooming in / out
AmeliaBR: The other aspect is loading content, e.g. higher-resolution
AmeliaBR: From a CSS perspective, they are going to be two
independent things to think about
AmeliaBR: Loading in separate content, have something similar to a
MQ scoped to a particular container that has a zoom state
AmeliaBR: triggers picture sources or whatever
AmeliaBR: Basic prerequisite for that is to have a standardized way
to describe pan + zoom
AmeliaBR: Which as a lot of similarities to scrolling environments
AmeliaBR: but the standard actions are a little different, different
translation of input;
AmeliaBR: different established pattern of movement
AmeliaBR: Other thing is that you don't necessarily start at the
beginning and scroll down, often starting in the middle
AmeliaBR: and usually not showing scrollbars
AmeliaBR: So established pattern of panning, semi-standardized
AmeliaBR: not always implemented in a way that is
keyboard-accessible, or devices otherwise unique wrt inputs
AmeliaBR: So much easier for authors to have a standard way to
switch into this mode, don't have to code up a lot of JS
AmeliaBR: and can make it more cross-platform and accessible
AmeliaBR: No proposal yet, but wanted to bring up to CSSWG, is it
something appropriate to address in CSS? Any opinions on
how?
<tantek> interesting, Google Maps is a *mix* of infinite pan in the
horizontal direction, while having blocking scrolling in
the vertical direction!
<tantek> Yandex maps also only does (infinite) pan horizontally and
(blocking) scroll vertically.
emilio: I was chatting about this with some of the zooming folks in
Gecko
emilio: Zooming and panning is limited to top-level content document
emilio: Depends on specific use cases you want to solve
emilio: Not enabling for iframes etc, is artificial limitation
emilio: Depending on set of use cases, documents already have all
these APIs, visual viewport API etc.
emilio: allow authors to react to these things
emilio: Depending on set of use cases, if enabling on iframes solves
them, could be relatively easy to do
AmeliaBR: That's interesting. So describing it as the same
pinch-zoom behavior that we have in most mobile browsers
AmeliaBR: but scoped to a specific element
AmeliaBR: One thing there, I don't know enough about mobile a11y if
there's standard mapping to keyboard controls for
pinch-zoom view
TabAtkins: I think this is great and interesting
TabAtkins: especially on touch devices, interaction is similar wrt
scroll vs pan
TabAtkins: but being able to opt into more pan+zoom interaction
easily on desktop would be useful
TabAtkins: You said something about being media-query?
TabAtkins: Needs to be a property modifying how we handle overflow
TabAtkins: particularly because of wrapping behavior necessary for
some cases
AmeliaBR: MQ thing was for the loading different resolution images
AmeliaBR: e.g. in a picture source
TabAtkins: Talking about level of detail?
AmeliaBR: Yes
TabAtkins: Level of detail is a much more complicated topic
TabAtkins: If we can separate from overflow interaction... it's much
harder
AmeliaBR: Agree it's the next level, and first level would be to
standardize pan-zoom interaction
AmeliaBR: and zoom part of it, so long as it's exposed to authors so
they can detect the desired level
AmeliaBR: that can be JS at first
AmeliaBR: and work on declarative way to do that as we go along
AmeliaBR: You brought up another point, tantek brought up too,
AmeliaBR: in some environments, such as maps, you want a wrap-around
effect
AmeliaBR: If you scroll to the end, scrolls back to the beginning;
spherical or cylindrical coordinate system
AmeliaBR: Other areas in CSS where it might be useful, like an image
gallery
AmeliaBR: where you scroll to the end, end up at the beginning
AmeliaBR: Again, slightly separate from panning interaction itself
AmeliaBR: but is also a relevant part of the discussions
heycam: I think it's worthwhile thinking about this further
heycam: My one concern is that we know what the full set of
requirements are around panning and zooming
heycam: so that we don't design a feature that goes 90% of the way,
but the last 10% requires reimplementing everything
heycam: E.g. some JS things let you pinch-rotate the map
heycam: if not a good way to do that, they authors might feel like
re-implementing everything
<tantek> oh yeah, there's also two-finger-tilt in some maps!
heycam: Might want to list what are the missing features, that
doesn't allow doing maps online
heycam: what's missing/janky
heycam: so we know the design space
smfr: Echo some of heycam's concerns
smfr: Different clients have different needs
smfr: some have very specific requirements
smfr: anything we make might not be enough, end up using JS again
smfr: Maybe we should focus on primitives that people require to do
this
smfr: one is always getting gestures right
smfr: sometimes it's vertical scroll, sometimes it's pinch-zooming,
inconsistent
smfr: WebKit had some non-standard events like this
smfr: Different areas of the page with different zoom levels, could
have confusion wrt MQ or something
smfr: Need to figure that out
AmeliaBR: Just answering to last bit about CSS transforms, that's
how I picture it
AmeliaBR: similar to CSS transforms or SVG viewbox, where it is a
localized transform that gets added to that stack
AmeliaBR: That's how it was originally specced for SVG, that there
would be a user interaction that ends up changing the
viewbox transform
AmeliaBR: That never got implemented in browser versions of SVG
dbaron: I agree with a lot of the concerns brought up so far
dbaron: a lot of panning and zooming is complex behavior
dbaron: as mentioned
dbaron: Also many sites change fragment of the URL in response to
panning and zooming, so you can bookmark where you are
dbaron: An interesting thing to investigate, if we do or don't want
to do something, requires a more concrete proposal about
something to add
dbaron: and an analysis of how that thing is useful for all the
consumers that are out there
<dbaron> Example of the pan/zoom results being in the URL (in a very
common format for putting it in the URL):
https://www.openstreetmap.org/#map=18/43.45397/-80.49867
<tantek> could see pan as an alternative to scroll, meaning it wraps
around in that dimension. that seems like a nice
incremental enhancement.
<tantek> gmap-pedometer is also horizontal pan, vertical scroll
fremy: I think that's similar to what other said before
fremy: Map use case, it's unlikely to desire to do in CSS
fremy: When you start to do zooming, dimensions of pixel changes
over time
fremy: with dynamic contents
fremy: it's easier to adapt yourself as zooming
fremy: than to back-propagate to elements shown
fremy: For use case for maps, highly unlikely anyone would prefer
CSS solution
fremy: but other cases
fremy: if you include PDF or SVG documents
fremy: Sometimes it's really nice to be able to zoom on them
fremy: and these contents do not react to gestures
fremy: so more reasonable use case to focus on these
fremy: So you really want to provide view on fixed contents
fremy: For maps, need to know where user is, fetching data to get
new info, new tiles, etc.
fremy: I'm not sure it would work for a world map to fit in CSS
pixels
fremy: At least for dynamic use cases, seems highly unlikely for CSS
to provide a solution
fremy: so if working on that, suggest to focus on static use cases
fremy: You want the effect, but don't want to include an entire
library
chrishtr: In addition to what fremy said, about dynamic scenario,
where devs want top optimize pixels at different zoom
levels and to ??
chrishtr: A lot of maps these days are drawn with WebGL anyway, I
don't think this approach would work with WebGL
AmeliaBR: Could work if you have a top-level DIV which maintains
interaction with users, and passes things as events
AmeliaBR: just as many things use position on scrollbar to trigger
things, but still using normal scrolling
chrishtr: Common gestures across sites would be useful
Rossen: I think most everything was said already
Rossen: Want to underline here, still the motivation or use case
here involves quite a bit of complexity
Rossen: Zoom as a gesture, as a capability of a presentation system,
is a very overloaded behavior, that has many different parts
that more often than not apps are hooking into
Rossen: Initiation of zoom vs when it is already steady
Rossen: visual zoom, layout-affecting zoom
Rossen: semantic zoom, going through levels of different categories
of app logic
Rossen: loads / unloads resources
Rossen: so this is also a type of zoom
Rossen: Tab summarized as, what are primitives we're missing here?
Rossen: When we thought about this in the past
Rossen: and attempted to extend zoom for application developers
Rossen: the main point was, what are the primitives that a platform
such as CSS needs to provide
Rossen: capabilities and observability of it
Rossen: To extend that we do to today, quite far on this journey
Rossen: can observe types of transforms applied, etc.
Rossen: But you also mentioned something interesting
Rossen: around a11y, and this being able to help a11y
Rossen: What do you mean by that?
Rossen: is that the ability to use zoom as an intent? or are there
experiences broken today?
AmeliaBR: Specifically about existing author code and libraries
aren't necessarily working well with different ways people
interact with their computer
AmeliaBR: Pan and zoom via keyboard controls is very opaque and
inconsistent from site to site
AmeliaBR: just by standardizing it, we could move towards the
browser controlling that standard interaction
AmeliaBR: and making sure it's accessible for all the ways people
interact with their computer
AmeliaBR: Being able to zoom is also an a11y issue, but not
necessarily going to line up with author's decision that
certain content is zoomable
Rossen: Usually what we specify here, we specify different modality
of input
Rossen: and capability of apps to provide the zoom experience or
behavior
Rossen: whether [lists input actions that all translate to same
intent]
Rossen: Reality is these will differ vastly between capabilities of
device
Rossen: and standardizing on these types of gestures or higher-level
intents
Rossen: will be more troublesome than if we identify primitives
missing in the platform to allow awareness of this thing
happening
TabAtkins: I strongly agree with idea that this would be really
useful for a11y, because not relying on bespoke and
incomplete JS solutions to a very common modality
TabAtkins: As something becomes common, if it's addressed by random
JS solution, won't be accessible to people not having
same setup as JS author
TabAtkins: Capturing, as Amelia says, that this is meant to be a pan/
zoom thing
TabAtkins: As dbaron says, we need a concrete proposal
TabAtkins: I propose two parts
TabAtkins: 1. new generic property that switches into pan+zoom mode
TabAtkins: 2. A gesture-based JS approach, so you can hook that, and
then roll your own pan+ zoom
TabAtkins: So you can roll your own, as people currently do with
'overflow: hidden'
<tantek> +1 TabAtkins
TabAtkins: So, CSS side that does things automatically as long as
you do simple thing
TabAtkins: and JS side that standardizes pan+zoom gestures, and lets
people hook that to do further stuff
TabAtkins: build on top of mouse/keyboard gestures etc.
<smfr> not scroll events (they are reactive, not prescriptive)
<smfr> say input events like mouse and wheel
AmeliaBR: That's a useful breakdown
AmeliaBR: Also need to take into consideration what exactly overflow
would look like, all different things that need to be
considered.
AmeliaBR: semantic gesture events, for pan+zoom
<tantek> was tilt explicitly excluded or just not brought up?
<TabAtkins> not brought up
<tantek> e.g. Google maps on a touch device, two finger up/down
gesture will tilt the map up/down
AmeliaBR: One question, who would be standardizing group for adding
new events?
<tantek> good question, what would the TAG say?
TabAtkins: I think WICG until it gets picked up by DOM?
fremy: But we do have CSS events too
smfr: We also have scroll events
smfr: You want all the input events to be defined in the same place
<tantek> pan / zoom / tilt / rotate
fantasai: In addition to capturing the gestures that would
correspond to pan/zoom/etc
fantasai: I think if you had pan/zoom mode for overflow, we have
currently a lot of APIs for getting the current scroll
position and for directing to go to a particular position
fantasai: You'd probably want analogous methods that would let you
do the same things in pan+zoom, e.g. get zoom level or set
zoom level
<tantek> +1 fantasai, zoom level equivalents to scroll settings
<tantek> The only request I have is to include tilt & rotate in pan
& zoom considerations / designs
Received on Monday, 3 August 2020 23:43:07 UTC