- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:39: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 Snapshot
------------
- RESOLVED: Move contain-1, cascade-4, easing-1 to the official
snapshot
- Grid was argued to not be ready to move into the official section
due to the number of outstanding issues.
- Align was argued to not be ready to move into the rough interop
section due to the sections on display:block not being
implemented yet.
- RESOLVED: Move writing-modes-4, display-3, font-loading-3 to the
"fairly stable" bucket
- Color-4 was not ready to move into fairly stable as it still needs
more work.
- Fonts-4 was not ready to move into fairly stable as it had too
many open issues, though may be moved later in 2020 when the
spec is closer to CR.
- RESOLVED: Have snapshot buckets all be sections
Masonry Layout
--------------
- There's a new explainer for masonry layout (Issue #4650) with more
details on the proposed spec:
https://github.com/w3c/csswg-drafts/blob/master/css-grid-2/MASONRY-EXPLAINER.md
- There still wasn't agreement on if masonry layout should be grid 3
or on its own. An issue will be opened so it can be discussed
further.
- Masonry layout works for both columns and rows, but fails if set
on both.
- An issue will be opened on how masonry layout interacts with
intrinsic size. The definition in the explainer seems like it
will need additional details and some possible solutions were
proposed.
CSS Backgrounds 4
-----------------
- RESOLVED: Close #4996 (Suggestion: “background-opacity” CSS
property (as suggested by CSS-Tricks.com)) and #4706
(`background-filter`) as no-change; filter() is what's
intended to solve these cases.
Foldable & dual-screen devices
------------------------------
- dlibby gave an update to the group on the changes that have been
made for multi-screen extensibility based on the previous
feedback.
- Solving for multiple geometry across multiple folds seems like it
will require complex calculations and some people in the group
believed that for simplicity the original scope should be just
multiple folds without complex geometry.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b
Scribe: fantasai
CSS Snapshot
============
github: https://github.com/w3c/csswg-drafts/issues/4715
astearns: I think all we need to decide is which specs go in which
category
astearns: At the moment, there are four specs proposed to graduate
to official CSS
astearns: 2 to graduate to "rough interop"
astearns: and 6 into "fairly stable"
astearns: Proposed to add to official set
astearns: Grid 1
astearns: Contain 1
astearns: Cascade 4
astearns: Easing 1
fantasai: I don't think Grid is stable enough yet
fantasai: Shouldn't go into snapshot in the current state
fantasai: Lots of open issues
fantasai: Also publication is still blocked on test cases
Scribe: heycam
chris: What does stable mean?
chris: People are relying on it
fantasai: The original purpose of the snapshot--might want to
rethink, but--we had a whole bunch of specs that were
basically RECs
fantasai: but didn't have a completed "all tests pass, full test
suite" etc.
fantasai: Known limitations of the test suite, known bugs unfixed
fantasai: We wanted to capture the fact that these specs are
basically RECs, but have a few things need fixing up,
which might take a while
fantasai: The bar for getting into that top level is really high
fantasai: Another problem right now, we have a lot of specs which
should be in CR but are not
fantasai: The poster child for these: animations, transitions,
those kinds of things
fantasai: We added a note to the snapshot saying these are widely
implemented, with fiddly bits not worked out yet. That new
category
fantasai: Then for completeness, we have a bunch of CRs, may as well
put them in there. but they're not at the "this is a Rec"
level
fantasai: That's how we got to this point with those categories
fantasai: Not sure what we need from the snapshot right now
<dbaron> I'm not quite sure I agree with the description of the
third category
fantasai: The purpose of the snapshot was to communicate actual
status which was not obvious from the official status
of the specs
astearns: I propose we don't discuss the purpose of the snapshots
today
astearns: we have a list of specs that have been suggested to add,
we can just move through them, and choose not to move
individual specs if we want
astearns: for the remaining things, that are being considered to be
put into the official section, any objection to contain-1,
cascade-4, and easing-1?
<TabAtkins> I object to Grid being omitted; I don't think that this
is worth anything to authors if something of Grid's
practical status is omitted.
fremy: It's really weird that you would have contain but not grid
florian: contain is a rec, grid is not
fantasai: Grid is not stable, the spec text is not at the same level
of stability
TabAtkins: Regardless of still tweaking grid, authors are depending
on grid in its current form in production all over the
place
TabAtkins: If it's not considered stable for the snapshot, I'm not
sure what message it's communicating if grid is not there
fantasai: It wasn't originally intended for authors
fantasai: hence we might want to discuss the purpose of snapshots
dbaron: I think Grid is in a similar state to what we thought about
animations a few years ago
dbaron: when it went into this category
astearns: The first category is "roughtly interoperable"
fantasai: Grid belongs there, not the top category
AmeliaBR: Three categories are: official stable specs, roughly
interoperable but needs more spec work, fairly
stable but needs more impl experience
AmeliaBR: transitions, animations, grid, these are all in the "rough
interop" category
AmeliaBR: moving one up and not the others, not sure what the
argument is for that
astearns: To make some progress, I didn't hear objections for
contain-1, cascade-4, easing-1
<dbaron> (BTW, I think I was confused about what was proposed to
move where when I made my last comment.)
RESOLVED: Move contain-1, cascade-4, easing-1 to the official
snapshot
astearns: Two candidates for adding to "rough interop"
astearns: align-3 and cascade-4
fantasai: I thought cascade-4 was at the top now?
astearns: cascade-3 is in the official part, cascade-4 is currently
in the "fairly stable" part
fantasai: cascade-4 I think is revert + scoping?
fantasai: shadow DOM scoping stuff
dbaron: I have comments on align, but maybe we should talk about
cascade first
florian: cascade is part of the resolution we just took
astearns: Sorry, my duplication problem
astearns: Let's talk about align
dbaron: One question about align is to what extent it's roughly
interop varies depending on what you're talking about
dbaron: Align is pretty interop if you talk about it applying it
flexbox
dbaron: but for applying display:block, it's mostly not implemented
at all
dbaron: so I think that makes it a little unclear where it should go
here
AmeliaBR: Are the parts of align that were originally defined in
terms of flexbox/grid, is that text still in those spec?
or has it been moved out to align
fantasai: Believe it's in flexbox, was never in grid
astearns: Seems like enough for me not to move it up to "rough
interop"
heycam: Might want to split out the application to block to a
separate level
astearns: Yes but there's still value to having the aspiration in
the current spec
chris: There is a cost to splitting it out, can cause impls to slow
down
dbaron: In this case, we're in a position where the longer we wait,
the more likely we'll have compat problems if we do it
dbaron: to the point that from a Gecko perspective we wouldn't be
comfortable implementing first
dbaron: If we impl, find it is compatible, nobody else impls, then a
year later we find it's no longer compatible, and we have to
take it out
astearns: For snapshot purposes, let's move on
astearns: The last category is "fairly stable"
astearns: 5 spec suggested to move into it
astearns: writing-modes-4 (fairly small), display-1, fonts-4,
font-loading-3, color-4
chris: Despite being the editor, I will argue against color-4
chris: It's not quite ready
chris: The working color space needs to be added
chris: fonts-4, I would argue for that
chris: The variable font part is good, rest is fairly reasonable
chris: I will resist splitting out the color font stuff
chris: I want to encourage impls by having it in there
fantasai: There are a lot of open issues on fonts-4
chris: 67 of them
fantasai: Putting it into stable-ish category usually indicates
fewer issues
fantasai: In terms of open issues, what does that look like?
chris: Lots of little issues. a pile related to generic font
families, ~20 of them
chris: Many will be closed with no effort or dealt with
chris: Think it's reasonably mature though
fantasai: If it's reasonably mature, we should try to get it into CR
and push it forward
fantasai: If it makes sense, push out the generic fonts stuff to
level 5...
chris: I did ask i18n for wide review today
chris: but I give them a 3-6 months to CR guesstimate
fantasai: I would love to see fonts-4 in CR
fantasai: At that point it would be great to add to the snapshot
fantasai: but given there are significant open issues, I don't think
it qualifies as "fairly stable"
fantasai: but I think you're not far from there, could probably add
it later in 2020
astearns: So let's not add it to the snapshot for now
astearns: We're down to 3 new candidates
astearns: writing-modes-4, display-1, font-loading-3
dbaron: I would like to change display-1 to display-3, since
display-1 doesn't exist
astearns: Any concerns with those three specs going into the "fairly
stable" bucket?
astearns: any objections?
RESOLVED: Move writing-modes-4, display-3, font-loading-3 to the
"fairly stable" bucket
astearns: Organizational question about the buckets:
astearns: Two are sections, one is a note. why not have 3 sections?
fantasai: I think that would probably make sense!
astearns: Any objections to having 3 sections?
chris: sgtm
RESOLVED: Have snapshot buckets all be sections
<dbaron> FWIW, I think I somewhat preferred the note setup rather
than switching to sections, but I'm ok with sections
<fantasai> dbaron, why?
<fantasai> not that I necessarily disagree, just want to know your
reasons :)
<dbaron> fantasai, I guess I liked the idea of the snapshot defining
one thing rather than three things
chris: Who's pushing it forward? florian made the first draft
florian: I am the editor
florian: I'm OK with doing some of it
Scribe: fantasai
Masonry Layout
==============
github: https://github.com/w3c/csswg-drafts/issues/4650
explainer: https://github.com/w3c/csswg-drafts/blob/master/css-grid-2/MASONRY-EXPLAINER.md
example: https://codepen.io/jensimmons/full/QWjqbJj
heycam: Small update since we last talked about this in A Coruña
where jensimmons gave a great introduction
heycam: Since that time, Mats has done some refining of the idea in
the issue
heycam: and has landed a prototype in Gecko
heycam: Want to get feedback
heycam: Also written up an explainer doc
heycam: Thought it might be helpful to have a more high-level
description
heycam: so not wading through GH issue
heycam: Don't know whether people are wanting to dive into
discussions about particular aspects of the proposal or not
heycam: Now that we have a prototype and an explainer, might be
worth people filing individual issues against the proposal
astearns: definite +1 to individual issue
fantasai: Great to have individual issues. Why not have a FPWD? We
have agreed to work on it.
heycam: Seemed like people were not sure about whether this should
be a grid feature or not
fantasai: When we come up with early stage work; we're often unsure
about many things. Doesn't mean we don't draft it up and
publish it.
AmeliaBR: Can we agree to adopt this concept as described in this
explainer as something we want written up in css-grid-2
spec or grid-3?
AmeliaBR: So question is can we agree to adopt what's written up?
fantasai: Thought we already agreed to adopt.
heycam: Thought we only agreed on the idea.
heycam: If people willing to resolve on, for now, keep this as
something to the grid model
heycam: add to grid-3
astearns: We officially agreed to adopt and assigned editors
jensimmons: There seemed to be a lot of debate in the group about
whether built on grid
jensimmons: Example, fallback is grid, very nice
jensimmons: Idea that Mats had to use masonry as part of Grid spec
means you get Masonry in one dimension while all power
of grid in the other dimension
jensimmons: so rows can be masonry and columns are full power of grid
jensimmons: But other ideas, certain people very strongly held
opinions
jensimmons: didn't like using Grid as the place to do masonry,
wanted display: masonry
jensimmons: I've seen some reactions from folks on Twitter etc.
jensimmons: "you can already do this, why new thing", Well no you
can't
jensimmons: They think of it as multicol or flexbox
jensimmons: Open question, should this be part of Grid
jensimmons: But enough of a disagreement that we weren't sure
florian: Remains an open question, will have to dive in at some
later point
florian: but even if it's an open question, can still decide if it
starts in Grid 3 and split later or start later and merge
later, but should put it somewhere
<fremy> (votes for separate spec)
dbaron: Also one other distinction here, worth thinking about
dbaron: To what extent we want to put prototyping into formal spec
language
dbaron: vs having documents about those things that are more
example-driven
dbaron: Some amount of formal spec language
dbaron: but serve a different audience as part of trying to solicit
feedback from people who might use the thing
fantasai: I don't see why that needs to be a separate doc that's not
adopted by the WG.
fantasai: I think publishing a side explainer that's not official
work of the working group.... seems like not part of
official work of WG.
iank: Gives impression to Web devs that they can give feedback
dbaron: Just because it's an explainer doesn't mean it's not
official working group work. It's in the repo
fantasai: [said stuff that did not get captured, likely about
how if publishing stuff officially is offputting
feedback, that's a problem that should be addressed,
not worked around by publishing stuff off-site]
dbaron: Idea of explainers was to address that problem
Rossen: Seem to be getting off topic
astearns: Let's put aside how we work and where work happens, look
at demo
<jensimmons> demo: https://codepen.io/jensimmons/pen/QWjqbJj?editors=1100
<jensimmons> display: grid;
<jensimmons> grid-template-rows: masonry;
<jensimmons> grid-template-columns: repeat(auto-fill, 20rem);
jensimmons: Mats's design is elegant
jensimmons: Shape of this layout can be accomplished in multicol,
but the ordering cannot
Rossen: this is awesome
jensimmons: Responsive design style
jensimmons: narrower it's 2 col, wider is 4 or 5 columns
jensimmons: Content gets rearranged
jensimmons: but always in masonry style layout
jensimmons: One of the main reasons people keep doing this layout in
JS is because of lazy-loading
jensimmons: They want to load new content into the bottom
jensimmons: using a proper masonry layout, first levels of content
stay at the top, add to the bottom
jensimmons: with multicol, everything gets rearranged each time you
add content
jensimmons: [shows code]
jensimmons: This one is auto-fill columns of even size, but could
make different-sized columns... anything you can do in
Grid, can do in Masonry layout
jensimmons: Fallback, if you open in current FF, has
grid-template-rows: auto (default value), so everything
lines up and just have extra space in the rows
Rossen: Someone asked if only available for rows, suspect not
jensimmons: Could define columns as masonry
dholbert: Works in either axis
jensimmons: What happens if you put in both axes
dholbert: You can't, fails in one
dholbert: Probably behaves as none
AmeliaBR: Looking through explainer, thing that was new since last
time I saw this is how this interacts with intrinsic sizing
AmeliaBR: and way it suggests is to just use the 1st item that goes
in each column as the one that decides the size of that
column
AmeliaBR: which I guess is similar to fixed mode for table column
sizing
AmeliaBR: but it's a little weird, unsure if there are other
solutions for it
heycam: You're right, hadn't thought about the analogy to fixed
table layout
heycam: The grid items you know for sure will be in particular
column, they're the only ones you can rely on to size the
columns
heycam: can choose those that are placed in a particular column
heycam: or ones which by automatic placement
heycam: would go into a particular column
heycam: which is true of the items in the first row
heycam: Do agree it feels a bit odd, other items can't influence
sizing
heycam: I think you can by forcing them to be in the top row with
grid-placement properties maybe??
heycam: not sure what else you could do apart from not allowing grid
items to influence sizes
AmeliaBR: Question for those who know grid layout better than I do,
when we have regular auto layout with intrinsic rows
AmeliaBR: How does that handle cycles
fantasai: In grid layout, you have to do placement before you can do
the sizing of the columns
fantasai: because the sizing can depend on what's in it
fantasai: Grid placement doesn't depend on the size of anything
fantasai: You start putting things into slots, doesn't matter what
the size of the item is
fantasai: That's not true of masonry layout, which is where this
rule is coming in
fantasai: You need to know which column it's in to size it, but in
order to size the column, you need to know what's in it
fantasai: So the proposal is using the items that we know will be in
a particular column
fantasai: What we could do is do an initial sizing pass based on the
items we know, with an explicit column or in top row
fantasai: Then place all the items into appropriate columns, then
run the grid sizing algorithm on all of the items to adjust
the sizes but not re-place the items.
fantasai: So later items would also influence the size of the
columns.
fantasai: This could cause, depending on width -> height influences,
could cause them to shift higher/lower in their columns.
AmeliaBR: Way they approached it, seems simple as anything
AmeliaBR: Most of the time this layout seems to be used with
fixed-width cols
florian: Also if we take fantasai's approach, probably want a switch
it off, so that column heights can remain stable over time
as you load comments.
astearns: Comments on the proposal / demo?
astearns: I agree with fantasai that this should be in an official
document. We did resolve on doing that.
astearns: Let's open a separate issue for that question
astearns: Let's assume it goes into css-grid-3
astearns: and have the issue have discussion for why that might not
be the case
astearns: and come back to this next week
astearns: and decide if it goes into grid-3 or a separate module
astearns: Put your arguments into the issue soon
astearns: Thanks for explainer, do like having a more
generally-accessible version of our documents
astearns: I'm glad it's in our repo
astearns: and thanks for demo, cool to see
heycam: File specific issues on e.g. sizing
astearns: Break up into subtopics will help, yes
fantasai: I think we should be publishing our work, so we should
also consider publishing the explainer either as a FPWD,
or as a Note at some point.
Scheduling
==========
[discussion about when to schedule more 4-hour blocks to soak up some
of the excess agenda items]
[group would like to have more next week, details will be discussed on
mailing list]
Backgrounds 4
=============
scribe: TabAtkins
background-filter
-----------------
github: https://github.com/w3c/csswg-drafts/issues/4706
AmeliaBR: This issue, and the next about background-opacity, are
basically the same issue
AmeliaBR: When you have layered backgrounds, sometimes you want to
modify those backgrounds, or see one thru the other
AmeliaBR: Like have a dark overlay over a texture image
AmeliaBR: Or you want a slightly blurred image so it's not as
distracting from the text over top
AmeliaBR: Right now no way to do that
AmeliaBR: Some things you can do with blend modes, but not a lot
AmeliaBR: So today people have to instead put the bg on a
pseudo-element and abspos it behind the element's content,
and then use 'filter' on it
AmeliaBR: Suggestion is to add more properties that describe
filter-effects, or perhaps just a simple opacity.
AmeliaBR: One thing that immediately is brought up is that we have a
spec for this functionality - in filter effects, there's a
filter() function that should take an image, apply filters
to it
AmeliaBR: So could say "background-image: filter(url(...)
blur(...));"
AmeliaBR: But no impl of that
<faceless2> We implemented it yesterday!
AmeliaBR: Don't know the reasons for that, if there are technical
issues or just priority
<fantasai> There's also https://drafts.fxtf.org/filter-effects-2/
which has no FPWD or anything
AmeliaBR: Other side, about separating to properties, that might be
nicer from an authoring perspective to just reuse the
existing bg model, rather than trying to squish everything
into a property
AmeliaBR: But need to talk about whether people will implement if
specced in a different way
smfr: We do have stable impl of filter() in webkit
smfr: I like it because authors are used to filter property, this is
a simple way to apply that in a different context
smfr: And lets you do the classic thing of shipping one set of
images and changing them on the fly with filters to do what
you want
smfr: Plus you can animate the filters
smfr: So I like filter(), would like to hear from other implementors
smfr: There's also a proposal to support the same filters for canvas
smfr: So if they don't have it already, will need it soon anyway
smfr: Also, filter() can be used anywhere, like border-image. If
doing a background-* property, can't apply it to other image
properties
faceless2: One difference between background-filter and filter(),
background-filter applies to all layers after merging,
filter() is per-layer
faceless2: Also when trying to blur image, filter doesn't apply
beyond the bounds of the image
faceless2: Not a problem if you have a single image covering the
whole bg
faceless2: But if you're tiling the image, you won't get the desired
effect
faceless2: So I think there's still a usecase for a whole-layer
filter
fantasai: Good point
fantasai: There's a proposal for backdrop-filter property; it does
something else entirely.
<TabAtkins> It's not the background at all, actually
smfr: backdrop-filter is different
smfr: It renders what's behind the element, then filter it. *Then*
the element itself, including its background, is composited
atop it.
fantasai: So there's still another case for compositing the bg
layers together before filtering
smfr: Yeah, definitely a difference there. Use-cases for both
smfr: For backgrounds, if you're using colors you can use alpha.
smfr: Would be curious to see use-cases for bg-filter that wants the
whole bg at once
smfr: And if doing it for bg, why not for border? So you can blur
your borders? Feature-creep potential.
fantasai: I think there are cases of people using bg to make a
stretchable scene in several layers, and there you'd want
to composite them together before applying opacity
smfr: That's a good use case
astearns: Any response to smfr's question about other impls of the
filter() function?
iank: Have to check with the team
emilio: Seems like putting it in the image is the more flexible
thing to do
dbaron: Someone mentioned tiled bg images, and diff between blurring
each tile vs the whole set
dbaron: One control that's common here is what's off the edge
dbaron: One option is the edge is transparent black, vs closest
pixel, vs pretend you tiled
dbaron: So with that control you could get the effect you wanted
dbaron: Filter controls like that are generally applicable, worth
considering
AmeliaBR: That's called edgemode attribute on feGaussianBlur
AmeliaBR: filter() is, as defined in spec, should magically choose
edgemode based on tiling or not
<smfr> “For the <blur()> function the edgeMode attribute on the
feGaussianBlur element is set to duplicate. This produces
more pleasant results on the edges of the filtered input
image.”
AmeliaBR: If bg image is tiled, is does blurring smoothly.
AmeliaBR: So for what is getting filtered, I think that's worth
talking about, but if there's a concern, there are ways to
address that concern.
<TabAtkins> I can dust off the @filter rule proposal, dino expressed
interest in it again a while back...
AmeliaBR: Maybe there are use-cases for both "filter each layer" vs
"filter layers together"
AmeliaBR: But filter() function is def treating each image before
tiling/compositing.
AmeliaBR: Other question is why only bg?
AmeliaBR: I brought this up as well. If we did it as a separate
property, all the other similar groups would want a
matching prop, so could add a bunch of properties.
AmeliaBR: fill-image-filter, border-image-filter, etc
faceless2: Re: compositing borders together, table borders would
make me cry...
faceless2: And table bgs are stacked up as well, phew
heycam: I think it's not just an issue with tiling; agree we need
something to fix that.
heycam: Also stretching - before or after filter() could affect
things.
<TabAtkins> Yeah, blur() would act differently if applied before or
after stretching.
AmeliaBR: So, we have filter() in the spec. There are clear
use-cases.
AmeliaBR: Do we feel that, from an authoring or impl standpoint,
filter() isn't good enough and we need to look at new
options? Or is it good enough, we close this no-change,
and continue working on filter()
fantasai: I think this addresses a number of the cases.
fantasai: But think it doesn't address "I want opacity on entire bg
at once, but not on the text", which is a common use
TabAtkins: One of the things suggested there was a ::background
pseudo
TabAtkins: if you could put filter on that, could achieve that case
at least syntactically it's easy
astearns: Would end up with a lot of pseudos for each thing you
might want to filter...
astearns: Then you run into "well if you do it for bgs, why not
borders, etc"
TabAtkins: Well, so far it seems that filter per layer shouldn't be
handled by separate properties
TabAtkins: Pursue filter() function as preferred method for that
astearns: Do we leave background-filter issue open to deal with the
background-all-at-once case?
AmeliaBR: I think we should see more use of filter() before we say
that use case isn't addressed
AmeliaBR: Think we need wider use of the filter() before we can
conclude we need to address more use-cases
astearns: So we can do that - close these as no-change and use
filter() function
astearns: Objections?
RESOLVED: Close #4736 and #4715 as no-change; filter() is what's
intended to solve these cases.
Foldable & dual-screen devices
==============================
scribe: AmeliaBR
github: https://github.com/w3c/csswg-drafts/issues/4736
explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Foldables/explainer.md
dlibby: A few months ago, we wrote up initial thinking on this
project space. Specifically, foldables with 2 identical
screens. We've had a lot of feedback, a lot about more
exotic form factors or possible application to desktop
multi-screen.
dlibby: (shares slides from explainer) This was the proposal, a new
media feature, screen-spanning, with value describing
direction, and then environment variables for the dimensions.
dlibby: We went back to the drawing board based on feedback. Some
detailed comments about how this interacts with bezels and
so on, and how can we make it extensible to multiple dividers
/folds in different directions. So need more complex
environmental variables.
fantasai: This slide shows 4 panes, but 3 in the media query. Is
that correct?
dlibby: Yes, though that's open for debate. We're counting the
number of folds/divisions, not panes.
dlibby: For the environment variable, that means we then have an
array-like structure, needs a way to access the nth value.
Can't use comma, because that's the fallback. One
possibility is a nested function.
fantasai: Or could just use a space separated `env(divider-left 3,
<fallback>)`
<fremy> @dlibby: also, why not just divider-left-1, divider-left-2,
etc...?
dlibby: We then can start looking at more complicated cases (3 by 2
panes in example). Should there be different names to access
horizontal vs vertical, top vs left. Getting a little
overwhelming in complexity. Wanted feedback from WG about
whether there is a more generic way to describe this.
smfr: I don't really have a mental model of how content is supposed
to interact with the different screens. Can you pinch zoom on
one screen, or would that zoom the whole display? Or
scrolling, doesn't the divider line move relative to the
content?
dlibby: Our proposal was based on defining things in the “client”
coordinate system, doesn't change by scrolling. Zooming,
haven't looked at that. Depends on a pinch or layout zoom,
whether it changes the geometry in CSS px.
fantasai: Generally, we say pinch zoom shouldn't change geometry,
don't re-compute layout. But layout zoom would require
computing everything.
fantasai: On the slide, you're calling this 1,2,3,4 dividers for the
top row and then the bottom row. That's really confusing
to number in this wrapping fashion. I'd try to name more
like grid dividers, assuming continuous columns, maybe
taking the widest gap if they're not all the same.
plinss: I agree that number seems weird, but in multi-monitors,
they're not necessarily be in a grid layout. We can't assume
something simple if we want to include that.
florian: And desktop screens are often different sizes.
plinss: And that will probably be true in future for foldable mobile
devices.
dlibby: Yes, we're trying to define in a generic way that doesn't
make geometry assumptions.
fantasai: But at a certain point, what are the chances that you're
going to make a design for inconsistent sizes of panels
arranged arbitrarily in space? Can we start with a simple
assumption of a grid-like layout. The original proposal
was for just a single fold.
plinss: But we should at least consider whether more complex is
possible.
fantasai: So long as simple cases stay simple.
dlibby: Agree with that. Kind of hard at this point in time to
imagine all application use cases and all devices in the
future.
<fantasai> extending to multi-fold from single fold wasn't hard, so
worth doing; extending to arbitrary geometry in space,
it's harder, so I wouldn't be opposed if there was a
proposal that handle complex cases but still kept simple
cases simple, but don't want us to get stuck on trying to
solve arbitrary geometry and make simple cases hard or
impossible for the next 5 yrs
astearns: Like with custom origins and masonry, it would be helpful
if specific questions are split out into separate issues.
Right now we have a giant discussion. As these questions
come up, please make separate issues.
dlibby: Agreed. Main goal for this f2f is to ensure we're on the
right track.
astearns: On that note, any other concerns that came up from the
presentation?
florian: I'm slightly concerned about how this media query will be
used & is it the best approach to the problem. E.g., can
you make your grid just nicely snap to the folds, without
needing to calculate all the environment variables,
margins, and so on of ancestors and previous siblings and
cousins.
<fantasai> +1 to florian, that's important consideration
Rossen: Snapping to the gaps is definite a use case, but we have so
many different layout contexts, and we already have ways to
make those sizings. Yes it uses calc. But if tomorrow we
change grid, we don't want to need to retrofit a lot of
magic. Trying to keep it simple rather than baking in
interactions with all layout models.
fantasai: I do think that florian's point is really important. We
don't want people to need to calculate many layers of
margin and padding to figure out where they are on the
screen.
Rossen: I disagree.
dlibby: There's certainly things we can look at, but I do think this
proposal covers the basic primitives to start to get
developers exploring things. Integrating with special layout
modes could be revisited.
<tantek> Curious about relation to "multi screen" work if any
<tantek> In particular I'm curious about possible overlap with
https://www.w3.org/2014/secondscreen/ specs and thoughts
fantasai: One thing to look at might be re-using fragmentation module
to avoid breaks. That's what fragmentation is designed to
address.
astearns: Most examples I've seen treat different screens
differently, two or more separate layouts. Not fragmenting
content across screens.
Rossen: And fragmentation is one-dimensional.
astearns: We have dave & Mike on the call, can we talk string-set()?
bremford: Let's push that back.
[scheduling discussion for possible long call next week]
Received on Friday, 15 May 2020 22:39:58 UTC