- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Sep 2021 19:43:01 -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 Box Model
-------------
- RESOLVED: margin-trim applies to flex and grid containers also
(Issue #3255: Should margin-trim apply to flex or grid
containers?)
- There was difference in the behavior expected by authors and the
implementation behavior for issue #3256 (Should margin-trim have
a 'floats' value?). Conversation will continue on github to
gather the use cases in order to determine the best solution.
- RESOLVED: margin-trim determines which sides to apply to as
described in #6643 (Issue #6643: Switch margin-trim to
boolean indicating sides rather than types of boxes to
trim)
Writing Modes & Shadow Parts
----------------------------
- There are several test cases outlined in issue #6609
(Directionality inheritance into Shadow DOM) that need to be
reviewed to see if the behavior the tests describe is correct.
fantasai offered to review, but anyone interested should also
look at the github issue and provide feedback.
CSS Color Adjust
----------------
- The proposal for issue #5469 (Should forced-colors override
border-image?) is to continue leaving border-image as-is and add
language to explain the rationale and that it's limited to
border-image.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0011.html
Present:
Rachel Andrew
Rossen Atanassov
Christian Biesinger
Oriol Brufau
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Brian Kardell
Jonathan Kew
Ting-Yu Lin
Peter Linss
Morgan Reschenberg
Cassondra Roberts
Miriam Suzanne
Regrets:
Tantek Çelik
Chris Harrelson
Dominik Röttsches
Scribe: fantasai
Scribe's scribe: florian & rossen
Agenda/Scheduling
=================
fantasai: Just wanted to suggest taking the first 3 issues in reverse
order
TPAC
----
Rossen: TPAC sessions are coming up soon
Rossen: Please add Agenda+ TPAC as needed
Rossen: We'll assume Agenda+ F2F is also for TPAC, but if specific
ones for TPAC please tag appropriately
<astearns> all overflow from today will go in as well
CSS Box Model
=============
Should margin-trim apply to flex or grid containers?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3255
miriam: margin-trim is designed to remove margins at the edge of the
box that are inside the box
miriam: e.g. you have h1 inside section, but don't want margin on the
h1 because section already has padding
miriam: or ...
miriam: That happens most often in block dimension, can also happen
sometimes in inline dimension
miriam: We were looking through issues around it
miriam: One issue was whether it applies to flex or grid containers
miriam: And idea is to let it apply to both of them
jensimmons: sgtm
florian: Haven't thought deeply, but wfm
Rossen: Does this have an affect on alignment?
fantasai: Only to the extend that if you only trim alignment on one
side of the box, you'll have alignment on the rest
Rossen: So margin-trim is pre-alignment
fantasai: For instance, things would not longer be centered if you
trim on some sides
Rossen: Might check if this is desired effect, but sounds good to me
Rossen: Anyone else?
Rossen: Any objections?
RESOLVED: margin-trim applies to flex and grid containers also
Should margin-trim have a 'floats' value?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3256
miriam: Question is should floats be able to do margin-trim
miriam: It seemed to us that floats that are at the edge of the box
that have a box that would impact the box should be
considered the same as any other margin against the edge of
the box
miriam: There might need to be special definitions to define
precisely when floats are impacted
miriam: but don't need ability to control separately
florian: I think we need some amount of independence
florian: Antenna House Formatter has proprietary controls
florian: for e.g. controlling the margin between two floats
differently from margin between float and edge of the page
florian: when being particular about layout of complex documents with
floats
florian: (not floats as substitute for grid, but actual floats)
florian: then you do want that kind of control
florian: Float to float margins and float to text margins are often
different
florian: Some amount of float margin trimming explicitly is needed
miriam: I was thinking if we think of the trim as coming from the box
edge, we could maintain the exclusion box of the float with
the margin so if it's pushing anything else that margin is
still there, but it's trimmed as far as the box is concerned
miriam: That seems to make sense to me
miriam: and that wouldn't need manual control
iank: Should this just apply to in-flow elements?
iank: That seems to be the main use case here
iank: ...
florian: What would apply then? If I do want to trim the margins of a
float
florian: for the purpose of not pushing other floats apart, it would
work, but if not, then we'd need another property
iank: It's a bit hard for me to reason when we don't have
particularly strong use cases one way or another
iank: use case described seems to be for in-flow children
iank: Consider the out of flow position case, not intending to act on
that
iank: floats seem in-between to me
miriam: If the section that the float is in is wrapping the float
miriam: e.g. is a block formatting context root
miriam: then I would expect the float the behave as in-flow wrt that
box
miriam: The margins on the float would be pushing the size of the box
which is exactly what we're trying to avoid here
fantasai: I think that it makes sense to apply trim to floats. You
want to have a solid control of the vis edge of the new
box. Considering a section with content and float that has
margin, done so content doesn't clash. If on top however
you want to trim it so that it doesn't get displaced
compared to rest of content.
florian: You need to trim all such margins. It makes sense to trim
all of margins as well as inline.
iank: For that specific case I don't think trimming the float is
warranted
iank: e.g. suppose you put 5px margin around the float, then want
that to stay all around
fantasai: Not sure you want that margin necessary. Mostly vis content
is what you want to align to. If you want to get the edge
of flow and text to align so you can put a margin around
you can. That way if float comes later in flow it has it
but not at the top.
fantasai: You can also skip using it. Use selectors for these first
elements to remove margins etc.
jensimmons: I think it could be confusing if margin-trim works
sometimes and not other times
jensimmons: "it counts if it's an image in a float, but not if ..."
It's a lot to keep in your head
<emeyer> +1 to @jensimmons point
Rossen: I'm closer to iank's opinion here... generally speaking,
float layout is not inline layout
Rossen: They take part during inline layout, however in all
implementations floats are kept separately based on whether
left or right float alignment
Rossen: and float layout is wrt all floats themselves
Rossen: We go to great extent in float algorithm in CSS2 to avoid and
minimize the dependency an inline content and floats as much
as possible
Rossen: Position of float wrt content ...
Rossen: seems odd
Rossen: because even a float that comes in the beginning of the
content, that more or less guarantees part of first line
Rossen: That float can be left or right
Rossen: and really left margin doesn't make sense for right float and
vice versa
Rossen: seems very specific to make that an automatic behavior by
layout algorithm
<iank> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645
fantasai: This is about trimming margins on content of all other
layouts - block, flex items, grid items. etc.
fantasai: Should also trim floats
fantasai: Also not sure why concerned about inline layout, this isn't
inline layout
Rossen: Floats are out of flow
fantasai: Yes, they're taking out of their original position, but
they're in-flow in the sense that they affect the content
around them, unlike abspos
Rossen: Floats create geometry for laying out content around it
Rossen: Their placement takes place ahead of inline content around
them
florian: You talked about inline margins
florian: Discussion is about block-start margin of the float being
trimmed
florian: If you want to put a 1em margin around your floats to avoid
the text of your float crashing against the surrounding text
florian: it doesn't necessarily mean you want your float to be 1em
from the start of the block
florian: There's nothing to crash into above it
florian: It does depend on the document, but there are cases here
florian: Elika gave explanations already, did you want scans of books
or something?
miriam: I would follow up with with what Jen said
miriam: There are interesting discussions from impl point of view
miriam: But from author point of view, not making sense
miriam: If I have a box and I want to trim the margins at the edge of
the box
miriam: I would expect it to trim all the margins at the edge of the
box
miriam: I wouldn't expect some difference because one is floated or
not or whatever
miriam: ...
miriam: Also margin-trim is only applied at the box edges. It doesn't
affect how content is flowing together
miriam: It determines what happens when I have a box and a float
inside it or a paragraph or a header inside of it
miriam: I trim the margins when they are at the box edge, and those
are the only margins I'm trimming
florian: I support miriam's position. If you simplify the value space
and exclude one of them, you can still have individual
control by using selectors
iank: Apply to out of flow elements?
miriam: I would expect to things that impact the size of the box
florian: wrt abspos, whatever
Rossen: For purposes of computing scrollable area, they do affect
layout as an inline margin would
Rossen: Behavior that we just described with abspos element that has
large margin bottom, would still create a large scroller with
visibly nothing below
iank: Other thing I wanted to ask...
iank: Example where using margin-trim is desirable but also
margin-trim is desirable
iank: How would I get that back, if it does apply to floats?
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645
miriam: I think you would either use padding, or you would not use
margin-trim in that case
miriam: If you want different impact on different elements, you would
do it manually instead of using margin-trim
iank: Other question is, now that we have nesting, it's very easy to
implement effectively margin-trim now
iank: Does the use case for margin-trim become less due to this?
fantasai: Margin trim is going to effect all elements very simply,
but with selectors you'd need to drill down to descendants
fantasai: margin collapsing makes that complicated
fantasai: That's why we don't do it on table cells with selectors,
and why it'd be good here too
iank: If I want margin on the float and not the in-flow, then what do
I do?
fantasai: Then don't use margin-trim
fantasai: Isn't that the same question as with multiple items at the
top row of a grid? at that point you can't use margin trim
iank: It is common to want margin on the float and not the rest of
the content
fantasai: I think the reason you often see margin on floats and not
in-flow content that's supposed to align is because in-flow
content isn't visibly flush
fantasai: but we're working to make that possible, so you won't need
to add margin to the float to make it look like it's
visually aligned with the in-flow content
iank: I don't think that's entirely true...
iank: but maybe we should discuss in the issue
miriam: I don't entirely understand your example, Ian.
miriam: I would expect padding on the content
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9646
LHS still seems better?
Rossen: I think this is a great discussion and I certainly want to
see progress made here
Rossen: The use cases that I just understood make sense
Rossen: But I also think we need to do some more careful thinking
Rossen: Maybe talk through use cases and narrow down what's possible
and what's not, and try to figure out expectations
Rossen: so maybe take up again later
Switch margin-trim to boolean indicating sides rather than types of
boxes to trim
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6643
miriam: This one might be tied to previous
miriam: If there's a reasonable way to apply this to everything
without being specific
miriam: we can make margin-trim to make boolean on/off and indicate
the relevant axes
miriam: as values of the property
miriam: e.g. margin-trim: block;
miriam: most common values are probably all/block/block-start/
block-end but others might be wanted
miriam: Basically property would say which sides need trimming
<emeyer> I can think of many situations where I’d want to trim inline
margins on floats.
<fantasai> emeyer, note the property is set on the container not on
the floats ...
Rossen: On the face of it, I think it makes sense
Rossen: but does go back to what it applies to
Rossen: I don't know if your assumption here about floats is that
strong
Rossen: Even if doesn't apply to floats, wouldn't you expect it to
apply the same way
florian: Question is if you have choice of whether to apply to floats
or not, then there's a bit of an explosion
fantasai: We could make it into multiple properties
fantasai: but the 3 way choice is the current syntax
Rossen: ...
miriam: If we had only none | all
miriam: then could use this proposal
miriam: But if need to control what to trim, then need maybe another
property
miriam: But if specifying which sides to trim, and then come back to
whether we need control over what to trim?
Rossen: Thoughts?
miriam: Should we take the proposal on control over sides, and then
come back next week with question of whether to apply to
floats or not?
RESOLVED: margin-trim determines which sides to apply to as described
in #6643
Writing Modes & Shadow Parts
============================
Directionality inheritance into Shadow DOM
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6609
emeyer: WHATWG triage committee had questions about directionality in
Shadow DOM
emeyer: There's been several discussions there
emeyer: It's summarized in this comment I linked...
emeyer: I drafted some tests
emeyer: Wanted to ask CSSWG to confirm if test asserts are correct
emeyer: and if not to correct that
emeyer: Summary is if there is explicit dir value on any element
emeyer: then that value holds sway whether shadow or light DOM element
emeyer: [...]
emeyer: So if you set LTR on a shadow host then the slotted content
will be LTR even if Arabic
emeyer: but if set auto on the slot, then it will use its inherent
directionality
fantasai: What do you mean by inherent directionality?
fantasai: dir=auto is defined to resolved based on the directionality
of the first strong character, which is a heuristic and not
appropriate if you know the actual directionality of the
content
fantasai: Are you saying that when slotting content into a shadow
tree that has set directionality on its own elements, you
lose the information about directionality that was in the
light DOM on any slotted content
fantasai: are you saying that if you slot content with directionality
into some shadow structure, it loses its directionality?
bkardell: This is where this is stuck in verbiage. The spec doesn't
say and in order to write the spec we need to know what.
bkardell: What we have done is to capture all tests and some of the
answers. We need csswg to make sure the words being used
are correct.
fantasai: Happy to review offline
emeyer: Brian did great summary of the tests and I have my verbiage
of what should probably go in the spec
emeyer: Please take a look, review, review the test correctness and
we can move on to write it all up.
fantasai: There's a bunch of discussion on what the behavior should
be. Lost track of it
bkardell: This is why we did this through examples and some text.
<florian> I haven't reviewed the tests, but I believe that the
summary describes problematic behavior. To be looked into…
<fantasai> I just want to say that I think it would be very
problematic if using a component meant that the light
DOM's directionality got lost whenever that content got
slotted into the component
<fantasai> And I believe I said so in the thread a couple years ago,
though I don't know what's happened in the discussion since
<bkardell> fantasai: this is why we'd like you to review specific
tests holistically and tell us where you disagree, and
what is writeable
<fantasai> bkardell, I don't think my position has changed compared
to what I commented in the thread years ago
<fantasai> bkardell, if there's new information I might reconsider...
<florian> fantasai's earlier detailed explanation of what ought to
happen with directionality and shadom dom is at
https://github.com/whatwg/html/issues/3699#issuecomment-395876573
<astearns> thanks for all of the test-writing!
CSS Color Adjust
================
Should forced-colors override border-image?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5469
[Rossen reads Alison's comment:
There is special logic in the spec
( https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties )
for handling background-image in Forced Colors Mode:
background-image computes to none unless the original value
contains a url() function
Perhaps it would make sense to do something similar for
border-image to override gradients.
(I could see the argument for overriding a url() in the case of a
border-image since they're more likely to be used in a decorative
capacity, although I'd also lean toward keeping those in case
they carry semantics.)
]
fantasai: The question in the issue was, does the concern that caused
background-image to not be overridden also apply to
border-images, or are we just assuming that they should
behave the same?
fantasai: This question was not answered.
Rossen: We had a ton of feedback about background-image, problem to
override them
Rossen: But no feedback about border-image
fantasai: Why should you not override border-image?
Rossen: Because we never overrode them, so never got feedback about it
Rossen: Our preference is to leave border-image the same way
Rossen: since we never got any feedback over the years
Rossen: so don't want to change
Rossen: If we start overriding border-image today, it would be a
change
florian: So might be fine but we don't know for sure
Rossen: Problem is it will affect tail end of the Web
Rossen: So our proposal for this issue is to keep it that way
Rossen: Is that reasonable?
fantasai: Yes. We just needed some rationale that was specific to
border-image
Received on Wednesday, 22 September 2021 23:43:42 UTC