- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Jan 2022 06:26:56 -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 Flexbox
-----------
- RESOLVED: We will spec that grid, flex, and table fragmentation
align globally before fragments are created (Issue #6812:
Flexbox alignment and fragmentation)
- RESOLVED: We will not truncate margins at any break when aligning
globally for fragmentation (Issue #6812)
- alisonmaher will reach out to print formatters to get feedback on
the above resolutions. If they have a different opinion the group
will revisit.
CSS Values
----------
- RESOLVED: The mix interpolation function will only be used for
top-level values with various discussed caveats. mix() is
the name of the top level interpolation (Issue #6700:
Validity of generic interpolation function mix())
CSSOM & Fragmentation
---------------------
- The general agreement from the github conversation for issue #6513
(getComputedStyle and fragmentation) was to select a simple value
to return, create exceptions where compat demanded, and direct
authors toward existing fragment-aware APIs if they need an
accurate answer.
- On the call, there were concerns about breaking compat since these
properties have existed for a while, even though there isn't
interoperability. Suggestions were to do a deeper dive into
properties and specify a compat-friendly requirement or to
specifically state browsers handle this differently and there is
no interop. Discussion will continue on github to reach a
decision.
CSSOM View
----------
- RESOLVED: When an inline box is split by a block box, offsetWidth
and offsetHeight will include dimensions of block box
(Issue #6588: Needs more details for offsetWidth and
offsetHeight)
CSS Contain
-----------
- RESOLVED: Property and fontface rules always work in an @container
rule (Issue #6827: What happens to other @rules inside
@container?)
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jan/0003.html
Present:
Rossen Atanassov
Tab Atkins Bittner
David Baron
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Daniel Libby
Ting-Yu Lin
Alison Maher
Cameron McCormick
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Scribe: dael
astearns: Happy new year everyone. Thank you for coming back after
the break
astearns: On private list we have a backlog so we'll look for a
longer form meeting. If anyone has preference for when
please post to the private list
Flexbox
=======
Flexbox alignment and fragmentation
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6812
alisonmaher: This is about handling alignment when fragmenting. Issue
also applies to grid and tables
alisonmaher: According to spec it suggests align per fragment.
Flexbox is only that makes this suggestion. Can confuse
implementers and may imply flexbox is unique.
alisonmaher: Would it make sense to change to suggest align prior and
can ignore
alisonmaher: Advantage of ahead of time is it layout more similar to
non-fragment. Consequence is how to handle margins. Spec
says truncate at soft break and they can affect
alignments so may not want to truncate
alisonmaher: Firefox does not truncate
alisonmaher: Proposal: update to match Firefox for margins during
fragmentation and add similar language in grid and tables
iank: Broadly supportive
iank: When fragmenting, doing it globally somewhat makes most sense
when you look. Otherwise you can get things in unexpected
columns and not aligning at the end
astearns: I'm not entirely convinced of the preference for stitching
back together in way that looks more like unfragmented, but
not against the change
astearns: If there is a use case for align per fragment is that a
switch we can add, maybe like how we do box decoration
breaks where an author can choose?
iank: Potentially. I think for that case what we might do is treat
everything as start aligned and do alignment then
iank: One thing that should be said is this would match what impl do
in reality. Blink at the moment because we're adding proper
fragmentation and fixing bugs
iank: Theoretically possible to have a switch. Place where per
fragment makes sense is content-alignment. But that's different
dholbert: Justify content?
iank: No, talking about...what's the keyword...we don't have it, I
think only Firefox does. Let me look it up
dholbert: first-baseline and last-baseline?
iank: Ignore my last comment. I'm confused.
florian: Usually when it comes to things that relate to fragmentation
print formatters have spent more time on this. Prince at
least supports both fragmentation and flexbox. Might be
worth looking at what they do. If it's not what we're
proposing we should think about it more
iank: This is slightly larger than flexbox since it applies to grid
and table
florian: I don't remember if they do grid. Might
iank: For grid doesn't make a lot of sense to do by fragment
florian: I don't have an objection, but given it applies to things
important to print formatters it's worth looking at what
they do. We can make a revision and put a to do to look and
revisit if needed
astearns: Is there a good person to tag? I would go to Dave Cramer
but I'm not sure how much time he has for CSS
florian: That was my answer as well
astearns: Maybe we can tag Dave and see if he can give us an idea of
what Prince is doing. Somewhat convinced we should take the
proposal since it's what Firefox is doing. If there is a
difference we can think again
dholbert: Firefox supports the change. It feels like most coherent
thing to do
iank: That's what I came to as well. It falls out to make most sense
astearns: Prop 1: We will spec that grid, flex, and table
fragmentation align globally before fragments are created
alisonmaher: Correct
astearns: Do we need anything about margins in that resolution?
alisonmaher: Separate resolution
astearns: Concerns about that resolution?
astearns: Objections?
RESOLVED: We will spec that grid, flex, and table fragmentation align
globally before fragments are created
alisonmaher: Margins want when handling alignment globally shouldn't
truncate margins at soft breaks
astearns: Can we do that without causing any cycles in determining if
a soft break
alisonmaher: I think Firefox already doesn't truncate margins in
flexbox case so I think there's a prior for it
astearns: Okay. Interested in seeing test cases we can apply for
this. Seems to me lots of weird edge cases for particular
kinds of margins. I suspect not well tested
alisonmaher: Yeah
astearns: Anything more to discuss about margins?
dholbert: Additional point, when doing global alignment the thing
aligned is the margin box which is why it makes sense to
preserve the margins
astearns: When we are aligning globally we will not truncate margins
at any break
alisonmaher: We could say it generally
astearns: Prop: we will not truncate margins at any break when
aligning globally for fragmentation
RESOLVED: We will not truncate margins at any break when aligning
globally for fragmentation
astearns: Blink is going through this and will be adding new
fragmentation code. Test cases as you go?
alisonmaher: Yeah
astearns: alisonmaher would you ping Dave Cramer?
alisonmaher: Sure
CSS Values
==========
Validity of generic interpolation function mix()
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6700
TabAtkins: Making sure we agree what generic interpolation does and
if it's valid
astearns: Only concern is last comment asked for fantasai to clarify
TabAtkins: True. But not relevant for this, I think.
TabAtkins: We have a couple of mixing functions like color-mix and
calc. These functions have a type. Color-mix is a color,
valid where ever a color is. But generic interpolation
function, currently called mix(), I don't believe can be
same
TabAtkins: It can interpolate things without describable types.
Interpolate of a box shadow is only valid in box shadow.
TabAtkins: Proposal is mix() is only allowed as top-level value of a
property. That's all it would be produced as by UA, but if
authors use it they could not combine with other things.
Can't mix 2 box shadows and then add inset.
TabAtkins: I believe that's all this is about, verifying that's what
we want for the grammar of this function
TabAtkins: If no one disagrees we can resolve
smfr: Questions- if you have property with comma separated values
like backgrounds, can you use mix() in the list or is the whole
list a mix()?
TabAtkins: Great question. Hmm.
TabAtkins: I think still the entire thing. Even in lists of comma
separated we can have distinct syntax at a position like
background where only color in the last. We couldn't
interpolate a mix() with a color unless it's final. So
would have to be the entire thing
smfr: High level, how does this interact with animations? Can I use
it in keyframes?
TabAtkins: Should be usable anywhere that accepts a value. Value is
generatable by an animation so it should be a valid value.
You can interpolate to this. Things you can do by hand
should allow explicitly.
smfr: keyframe? only animatable properties?
TabAtkins: Yes, if property wasn't animatable then mix() wouldn't
have a meaning. Great question and not in spec. I suspect
should be properties that are not animatable mix is
invalid at parse time.
smfr: If you can spec in keyframes implies mix() can nest
TabAtkins: because you can mix between and mixed value and something?
smfr: Yeah
TabAtkins: True. Good clarification. mix() should be able to be an
entire argument of the mix(). You should be able to mix
mixes
smfr: Shorthands vs longhands when mix is the entire value?
TabAtkins: We had an answer. I believe it needs to be similar to
variable in shorthands, but don't recall exactly. Whatever
it was, we can't rely syntaxtically that something is a
shorthand so whatever we define has to work well for
shorthands.
TabAtkins: Mix should be allowed in a shorthand. Exact interpolation
I can't answer but should be as reasonable as can make it
smfr: Sounds good
astearns: Looking for resolution to define mix() as only top level
astearns: Issue also talks about adding another lower level value.
Punt that for now?
TabAtkins: Yeah, it's separate
astearns: But if we expect lower question is which gets the shorter
name
TabAtkins: My argument is the existing lower-level have longer names
like color-mix. Completely usable anywhere should get the
shortest name. No way to be generic low-level because we
need to know type to parse. Interp at the value level will
be type specific. mix() should have the short name and
others longer and more specific
astearns: Other questions or ideas?
astearns: Prop: The mix() interpolation function will only be used
for top-level values with various discussed caveats
TabAtkins: Should also resolve on name
astearns: And mix() is the name of the top level interpolation
astearns: Objections?
RESOLVED: The mix interpolation function will only be used for
top-level values with various discussed caveats. mix() is
the name of the top level interpolation
astearns: Since this issue discusses lower level, is that captured
elsewhere or should we open another issue?
TabAtkins: One talked about is numeric and that does have an issue
for it
astearns: I'll see if I can find it and link it
CSSOM & Fragmentation
=====================
getComputedStyle and fragmentation
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6513
florian: A while ago looking at definition of getComputedStyle and it
does not mention fragmentation. This is a problem because
element fragmentation gives multiple answer to value of
property. What to do?
florian: GH suggestion which is roughly okay with commenters is other
APIs are fragment aware so people who want per fragment
should use those. This API we should do simplest with tweak
for compat
florian: Simplest is return first fragment. Might need to tweak based
on historic impl. Assuming horizontal writing mode, height
of the block chrome returns sum, though Firefox returns
first. Probably not compat problem there, but might have it
elsewhere
florian: Suggestion is document that getComputedStyle returns based
on first fragment and we document compat issues separately
florian: Suggestion from fremy to make it a little smarter and answer
on last for other writing modes. I think I would suggest not
taking the suggestion. This will not be smart enough to
describe everything so you need fragment aware APIs
florian: If compat dictates smarter this could be one of the things,
but would rather not if we can keep it simple
TabAtkins: I think I agree. Don't think we can get smarter without
being complex. Going with simple answer of first fragment
is easier
iank: Not wild about first fragment. Larger set of problems about
client width and height and how they interact
iank: In a lot of libraries they compute to width and height and used
interchangeably. Someone using this naively they would get
unexpected results when printing. If you sum as I suggest in
the issue you get broadly expected
iank: I don't expect a large compat issue, but it's a little
un-intuitive
florian: Can we say unless documented we go with first fragment but
with block dimensions we sum up. And maybe for padding,
border, margin we take last for inline-end and block-end.
Maybe that's enough of an exception?
iank: What properties return used? width height padding border margin?
florian: More. Offsets as well
florian: width height margin padding, top left bottom right
florian: Another complication is we're baking selectors that let you
style different fragments differently and then any property
could have a different answer. Not exposed, but might be
coming
iank: With that we would start not to return...you can't really...a
lot will break if you set different margin-top per fragment.
Skeptical we'll need to do something for that case
florian: Even if we don't get that. For margin-bottom return the
first, last, depend on box-decoration-break? If compat
dictates we should take that
iank: Rather then applying general rule would be good to go through
cases individually and come up with answers. I suspect I agree
with margin and padding for first/last fragment but width and
height we want different.
iank: It would be better to do case by case
Rossen: I'm more closely aligned with iank then the simplicity.
Generally I'm all for simpler and more definitive answer. I
believe there will be unfortunate compat breakage we'll see
for apps building pagination-ish presentations
Rossen: I've seen a number of apps using multicol to drive book-like
experiences. For them, back in the time this is why we into
getClientRects and go down patch of fragment aware things.
Zooming out, not being able to know where a box starts which
is what you will run into if you only give results on first
fragment which could give you a result under the 2nd, that
would be unfortunate
Rossen: I'm closer aligned with iank's point
florian: Strongly agree we need something that's fragment aware. But
getComputedStyle isn't fragment aware. As to breaking
interop, we don't have interop.
florian: Another thing I forgot to mention is we don't need to get to
fancy APIs to get into trouble. We could sum heights, but
what to do with width when fragments have different width?
Or an inline that breaks 2 lines? Block that's across 2
pages? No answer in the spec
florian: We can go property by property as iank said. Having done
that for height there's no interop
astearns: Not that we break interop but that we break compat. There
are likely sites that rely on Blink's behavior. Risk
breaking them if we spec differently
florian: But if it's engine specific should we also not change FF?
Rossen: If they don't have bugs they're either not used for these
presentations or they've coded to adapt. I want to underscore
the point about compat vs interop. I'd be more concerned
about compat at this point
astearns: If concerned about compat and there isn't anything that we
can spec as safe, perhaps we explicitly say
getComputedStyle is not fragment aware, different engines
return different and we don't spec what to do
florian: Not terribly helpful
astearns: It's not. But going through what to do with every layout
property with interesting fragmentation when we can't spec
something interop, is that a wild goose chase?
Rossen: Sounds more academic than applicable. Do we have use cases
for alignment? These properties have existed for quite some
time so people work around it
florian: Confused how it can be true simultaneously that this is
sufficiently used that we can't change but unused that we
don't have to answer. If people aren't using this spec
simple or say undefined. If it is used would be good to have
a known behavior for interop
smfr: Might have legacy content on each browser relying on the
behavior
Rossen: epub viewers are built against 1 engine and for these
applications they have very specific code with very specific
behavior for the engine. Whatever that engine does is what
they'll get
florian: Not so sure. Paginators are frequently cross-engine.
iank: Specific example, a lot of people run chrome in headless to
generate pdfs. A lot of people doing that
iank: To my previous point, only properties we'd use layout dependent
is margin, padding, width, height, and the insets
florian: Also borders. Sizes don't change but box-decoration-break
might or might not have
florian: But yes, it's those
iank: I wonder if we can go through these and pick what is
reasonable. For example, for the edge type things, border
padding margin and insets I'll agree picking first or last will
be pretty compat. not huge burden on engines to sum on block
and take max on inline
iank: I think blink and wk do that already. Would be interested to
hear for gecko
florian: Not particularly hard. But in viviostyle there is a measure
of lazy rendering for a many 1000 book and having a blocking
call that forces you to layout isn't great. Maybe no way
around
iank: I can come up with examples that will render incorrect due to
that
florian: Yeah. For block maybe no way around. For inline maybe we can
just do first?
iank: Yeah. I'd like this consistent with client height. A bit of
precedence with inline element fragmentation. Might be wrong
there
chrishtr: No strong opinion, but maybe take this offline for specific
proposals?
chrishtr: There is #6588 on the agenda which we need for progress
astearns: Okay, will go back to GH on this issue and get a list of
properties we want to consider fully
CSSOM View
==========
Needs more details for offsetWidth and offsetHeight
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6588
chrishtr: Discussed Oct 6 and resolved that they should be computed
out of principle css box
chrishtr: If you have an inline split into multiple fragments with a
child that's block should the balance of the block be
included
chrishtr: No strong opinion in discussion. Weak opinion not to, but
implementation difficulty should be a factor
chrishtr: Engineers have been trying to simplify code and have found
that including it would be simpler to impl and give same
answer as getBoundingClientRect. Suggest include block box
in the bounds
astearns: Make sense.
astearns: Proposal: When an inline box is split by a block box,
offsetWidth and Height will include dimensions of block box
astearns: Objections?
RESOLVED: When an inline box is split by a block box, offsetWidth and
offsetHeight will include dimensions of block box
CSS Contain
===========
What happens to other @rules inside @container?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6827
miriam: Dealt with a version of this problem before
miriam: Containers don't have a global resolution. Specific to
elements and contexts
miriam: Need to know if allowed and what happens to have global
@rules like property or @fontface inside @container
miriam: On thread agreed for these rules we think @container should
be treated as true for all cases like these to be consistent
with previous decisions
astearns: No difference in having @fontface inside or outside a
container
miriam: Right
astearns: Reasonable to me
TabAtkins: Yep, agreed
dbaron: At first glance seems surprising. Are there other things that
work this way?
astearns: Talked about layer order previously
miriam: Yeah, layer order. I feel like also some name defining
@rules, but that's this so maybe we didn't. I think there was
previous art on this
TabAtkins: Ultimately they're always true or false, we can't make
them dependent on the query. The always true is
consistent. But we could say it's always false if that's
more reasonable.
dbaron: Curious why it's not syntax error and drop. That was one of
Rune's options
astearns: Would you like more time to consider and consult?
dbaron: If nobody else thinks it makes sense okay resolving. My
intuition is if we don't know how to process it shouldn't be
allowed
astearns: We can process fine. Slightly less surprising the rules
don't disappear
dbaron: Maybe. Okay
astearns: We are at time. Prop: Property and fontface rules always
work in an @container rule
miriam: Prior art was for @layer where @layer has no effect on name
defining rules
astearns: Anyone want to chew on this more?
RESOLVED: Property and fontface rules always work in an @container
rule
astearns: Thanks for calling in for the first meeting of the year.
We'll talk for the hour next week and have a longer call
later in the month
Received on Thursday, 6 January 2022 11:27:37 UTC