- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:37:46 -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 Align
---------
- RESOLVED: Baselines of a scrollable container should be clamped to
the scrollable area (Issue #7660: Not clamping baseline
position when scrollable overflow gives weird results)
- RESOLVED: When taking the first baseline of a row of items, we
check a shared first baseline, then a shared last
baseline, then the first baseline of the first item (and
vice-versa for the last baseline) (Issue #7641: How to
determine the last baseline of a flex container with
different alignment groups)
- RESOLVED: For multicolumns, use the lowest last baseline of all
columns as its last baseline (Issue #7639: How is the
last-baseline of a multi-col determined?)
- RESOLVED: Table baselines match grid (Issue #7655: Define last
baseline for tables)
- RESOLVED: Rowspanning cells participate only in first baseline
alignment of their first row, and last baseline alignment
in the last row (Issue #7655)
- RESOLVED: Default first and last baselines to be the fieldset
content's (Issue #7656: Baselines need to be defined on
fieldsets)
====== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/31
Scribe: fremy
CSS Align
=========
Not clamping baseline when scrollable overflow gives weird results
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7660
fantasai: TabAtkins can you project the test case?
TabAtkins: Yes
fantasai: This page shows a scrollable box which is an inline-flex
fantasai: The issue is that the text is bigger than the box itself
fantasai: so, the rest of the text is aligned to a line that is
well outside the box itself
fantasai: which doesn't make much sense
fantasai: the proposal is to clamp the baseline to the border box
Rossen: Do we also do this in the other direction?
fantasai: Good point, we probably should do it in both directions
asterns: What is the effect that this would do?
Rossen: Align "text" to the bottom of the scrollable box
dbaron: This would be based based on the initial scroll position?
fantasai: Yes
florian: What about overflow: clip?
TabAtkins: Probably the same?
iank: Well
iank: probably we don't want that because we resolved that
overflow:clip should not have any effect on the layout
iank: There is already some margin clipping anyway
dbaron: I agree, overflow:clip should not do anything different
because overflow:clip shouldn't influence layout
<emilio> +1 to dbaron :)
emilio: I concur as well
TabAtkins: Currently, the reverse issue exists
emeyer: Am I correct that the baseline can not be above or beyond the
scrollable area?
fantasai: Yes, correct
emeyer: Then, sure, no objection
dholbert: The correct rendering would be that the border would align
with the text
dholbert: but we don't want to do that, right?
Rossen: Yes, otherwise we would need to take a dependency on the font
size etc...
<dholbert> clarifying my question: I was asking if the border-top of
the scrollable thing would align with the baseline of the
text. And the answer was yes, it would
<dholbert> (in the "reverse scenario")
Rossen: So, the proposed resolution is to clamp the baseline
Rossen: Any other comment?
iank: Can we keep inline-block last-baseline separated from this?
iank: I don't want to change the margin behavior yet
TabAtkins: I'm fine with this for now
Rossen: Any objection?
RESOLVED: Baselines of a scrollable container should be clamped to
the scrollable area
Last baseline of a flex container with different alignment groups
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7641
iank: Blink would like to implement last-baseline alignment
iank: (by blink I mean me)
iank: but how do we find out what is the last baseline is a question
iank: Currently, anything that uses a baseline alignment should be
counted in
iank: if none are, you fallback
iank: There are groups however
iank: some might be first-baseline aligned, some might be
last-baseline aligned, etc...
iank: how do you choose? it's the question
iank: Maybe TabAtkins can elaborate
TabAtkins: I'm projecting the example on the screen
fantasai: If we consider a flex container with multiple elements with
baseline alignment
fantasai: We want the baseline of these elements
fantasai: but if you have last-baseline alignment only
fantasai: Should that count as the first baseline of that group?
fantasai: or should we bail out?
fantasai: And if you have both types of alignment in the first row
fantasai: these might not align with each other
fantasai: How do you pick in that case?
dbaron: I would like to propose something
dbaron: maybe the solution is that if you look for a first baseline,
first-baseline-aligned things should be used first
dbaron: and vice versa for last baseline
iank: Yes, I think most people agree with that
iank: an issue is what you do next
fantasai: If a page has a navigation bar
fantasai: and it's last-baseline aligned
fantasai: if most items have one line, but one has two
fantasai: if I align something with this, what behavior do we want?
fantasai: We can either use the last-baseline that every item
aligns to
fantasai: or the first baseline of each of these items
fantasai: I would posit that the shared baseline is a better guess
for what the author might want
<dbaron> I think what fantasai said seems reasonable as long as when
there are *two* shared baselines, we pick the one being
exported.
iank: To repeat that
iank: if we are trying to find the last baseline
iank: we would pick the shared first baseline as the last baseline
if that's the only shared baseline all we have
iank: and if we don't even have that, then we fallback to the last
baseline of the bottom item
fantasai: Yes
iank: Reasonable
heycam: Would not exporting a baseline be reasonable?
fantasai: We will always do that
fantasai: but right now we synthesize one
fantasai: that is rarely desirable
heycam: Isn't that enough?
fantasai: It's better to use any actual baselines, for the author
iank: The final fallback could be the first or last item
iank: I agree that the middle step is ok
dholbert: I'm not sure we don't always fallback
dholbert: I'm worried that we could get a weird stair-step effect
dholbert: things will be lined up
dholbert: but in opposite directions
dholbert: which might not look good, actually
dholbert: the synthetic is at least "logical"
fantasai: iank proposed to use the lower last baseline and the
highest first baseline etc...
fantasai: but if you have five items that are 1, 2 or 3 lines tall;
whether or not your item is at the top or the bottom, it
won't look very reasonable
fantasai: if you align with the shared baseline, the alignment will
look reasonable I think
dholbert: But if you are looking for a first baseline and there is
none
dholbert: I don't understand why the special handling is gonna make
things substantially better
fantasai: If you are aligning one line of text, it's more sensible
<fantasai> if you're asking for baseline alignment, you want to align
to text, not to fall back to a box edge, if possible
iank: My comment is that if you are trying to find the last baseline,
you could get the lowest in the first row
iank: this is kinda how tables work
iank: but the two solutions I most like
iank: is either use the first baseline item then use the fallback
iank: or fantasai's solution where there is a middle step
iank: both solutions look reasonable
Rossen: And if you had to pick?
iank: No strong opinion
iank: The first one is a bit simpler to implement because its has two
levels only
fantasai: If we are looking into multi-rows grid to align
fantasai: if you don't have the middle step, you will get worse
results
fantasai: because fewer things will align with each other
florian: Flex items contain text
florian: so it makes sense for them to have both
florian: but the container only has one line
florian: so I can't think of of any other relevant baseline is than
the shared baseline
<dholbert> No, flex containers can have last-baseline as well as
first-baseline aligned items
<dholbert> and can export both
<dholbert> (I think)
iank: You can look into it in two ways
iank: the question is that the fallback approach
fantasai: In the issue, iank suggested also to look for the lowest or
highest across all items
fantasai: this would give even better results
iank: Yes, this is another option I would accept
iank: I'm just worried a bit about the compat risk
dholbert: When finding the first/last baseline, would what you
described be the canonical algorithm?
iank: Yes
dholbert: Then I would worry about compat too, I think
dholbert: For the grid case, I agree that in most cases what fantasai
proposes makes more sense
dholbert: but when you have one flexbox with one item, which is a
common case, which would be confusing I think
dholbert: we could find the baseline of that first item
iank: It's an edge case
iank: you can get the correct behavior by doing nothing
iank: so, why would you do it if that's not what you want?
iank: I'm thus not very concerned
dbaron: After listening to fantasai's explanation, I'm reasonably
convinced that we want the fallback levels
dbaron: because some things might need to be changed later in the
design
dbaron: Otherwise, if you change things in one place, you have to
change consistently, which might be difficult
dbaron: the middle step enables to change only locally, and get
things to work anyway
iank: Seems like most people are aligning with fantasai's solution
iank: Anyone would object to that?
Rossen: Sounds like you will have to do the more complex
implementation :)
iank: Yes...
Rossen: Ok, any objection?
fantasai: Proposed resolution: when taking the first baseline of a
row of items, we check a shared first baseline, then a
shared last baseline, then the first baseline of the first
item
fantasai: (everywhere we can get away with it without compat issues)
<dbaron> (and vice-versa for the last baseline)
<florian> +1
iank: The only additional warning is that you can have a
first-baseline aligned thing in the first-baseline group, but
that seems fine
Rossen: Ok, no objection,
RESOLVED: When taking the first baseline of a row of items, we check
a shared first baseline, then a shared last baseline, then
the first baseline of the first item (and vice-versa for
the last baseline)
How is the last-baseline of a multi-col determined?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7639
iank: For multicolumn elements, we currently take the baseline of the
first column
iank: and implementations don't look for a last baseline
iank: maybe we should?
iank: But it's still an option not to, like we do today
iank: We can take the last baseline of the first column
iank: or of the last column
iank: or the lowest of all the columns
dbaron: Exporting the last baseline of a multicolumn sounds scary
dbaron: especially if you have balancing going on
iank: If you use the last column and you balance, it will often work
iank: but without balancing, you can end up somewhere random in the
height
fantasai: That seems the worst indeed
fantasai: I think the best would be the max, and second best would be
the last line of the first column
TabAtkins: fantasai just said what I was about to say
iank: The only caveat is that we probably don't want to include
spanned items
fantasai: Why not?
fantasai: If sounds like an rare case, but why not?
iank: (nodding)
fantasai: I think checking all columns is better
<rachelandrew> +1 to checking all columns
fantasai: In case you have a large image that doesn't fit at the
bottom of the first column
iank: I'm fine with that
iank: We have some compat constraints for inline-block
iank: but here it's ok
fantasai: Proposed resolution is to use the lowest last baseline of
all columns
Rossen: any objection?
RESOLVED: For multicolumns, use the lowest last baseline of all
columns as its last baseline
Define last baseline for tables
-------------------------------
scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/7655
iank: Tables work by taking the first baseline from the first row in
the larger table
iank: Importantly, we skip captions, this is intentional
iank: So how do we determine last baseline?
iank: First relatively obvious bit is we probably want the last row
iank: Given the resolution we just had for flex and grid, we can
probably do something similar
iank: So if you've got a lot of baseline-aligned items, we'll take
the first-baseline of those items and use it as the table's
last baseline; otherwise we'll synthesize
fantasai: Alignment expands baseline alignment for tables, says
align-content works on cells; "normal" looks at
vertical-align, but you can use first/last baseline normally
fantasai: So probably just want to take literally the grid behavior
and apply it here
iank: Yeah, fine with that
iank: Not implementing it yet, but seems fine
iank: Important is to not consider captions
fantasai: Agreed
iank: (I'll show Firefox folks some cases for why caption should be
ignored later)
heycam: How do spanning cells impact this?
iank: It gets a little complex
iank: This wouldn't apply until impls support align-content; if
something is spanning multiple rows, its first baseline
currently only contributes to its first spanned row
iank: And last-baseline, you can only get spanned cells affecting the
last baseline if you support align-content:last-baseline
fantasai: So a spanned cell only affects first baseline alignment in
its first row, and last baseline in its last row, and
that's it
fantasai: so it doesn't affect first-baseline alignment in its last
row, etc
fremy: When you synthesize, do you include the table border?
iank: Tables always have a valid baseline - it's complicated - if
there's a body, you have a baseline because you synthesize it
using the content edge of the first row
iank: I think if you have captions but no body there's no exported
baseline, so you'd synthesize from the table border
iank: Need to do some investigation on our behavior
fantasai: Proposed resolution: finding first/last baseline of a table
cell works same as in grid
iank: And last baseline of a table is taken from the correct
baseline-sharing group in the last table row
Rossen: Objections?
RESOLVED: Table baselines match grid, per details above
RESOLVED: Rowspanning cells participate only in first baseline
alignment of their first row, and last baseline alignment
in the last row
fremy: Should I modify Tables?
fantasai: We might be able to do it generically in Align.
fantasai: If we can't we'll ping you.
<br dur=54min>
Baselines need to be defined on fieldsets
-----------------------------------------
scribe: emilio
scribe's scribe: heycam
github: https://github.com/w3c/csswg-drafts/issues/7656
iank: fieldsets need their baseline defined
iank: They're special, have a <legend> on the border area
iank: and their contents are wrapped in a box with arbitrary display
type
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10714
iank: Implementations do wild things
iank: dgrogan has screenshots of what browsers do today
iank: My preference is to ignore the legend
iank: that's Chromium's behavior
fantasai: I'd like to argue for Safari's behavior
fantasai: first baseline from legend, last from content
Rossen: Why is that more sensible?
fantasai: Legend is the first bit of text that you see
fantasai: seems reasonable to align to it
fantasai: that should def. work
fantasai: not sure what the last baseline to be, but taking the last
baseline of the content of the fieldset makes sense to me
<fremy> +1 for aligning fieldsets with each other based on the legend
iank: I think I disagree, <legend> is like table captions
iank: They have smaller font-size, they're not the main content of
the fieldset
iank: first baseline should be actual content, that makes more sense
to me
fantasai: Would be great if web designers would weigh in on this
Rossen: One potential use case might be aligning multiple fieldsets
iank: Aligning to non-fieldset content is more common I think
dbaron: I think I lean towards agreeing with iank
dbaron: not that uncommon for fieldsets to lack a <legend>
dbaron: if we wanted to align to legend we'd need to define what
happens when there's no legend
dbaron: My sense is that it's common not to have one
<miriam> +1 Ian and David
<emilio> +1
<tantek> +1
iank: If you're aligning fieldsets with and without legends it'd be
weird
heycam: Agree with iank as well, legend is ancillary content like
captions
heycam: fieldset legend could also have multiple lines of text as well
emeyer: I'm looking at live dom viewer on irc
emeyer: I accept the argument that aligning to the legend is a bit
dangerous
emeyer: I have the feeling that many fieldsets don't have legend
emeyer: but I do see situations for all three kinds of alignment:
legend/first/last content
emeyer: If I had to pick one I'd choose first line of contents
emeyer: but I see use cases for the others
emeyer: there's cases where I might want to align to others
emeyer: I think both patterns would be common
fantasai: When you want first line to align, is there case where the
legends don't align?
emeyer: I can't think of a reason, I'd want the legends to align with
each other
emeyer: sometimes I want text outside to align with the legend
iank: If you want to align legends using top-alignment would work
unless there's non-fieldset content
emeyer: I probably would want the text outside to align with the
first line of content rather than the legend
iank: We could also add a switch to allow you to align to a legend if
that use case comes up
fantasai: There's an issue to allow choosing baseline alignment box
<fantasai> https://github.com/w3c/csswg-drafts/issues/1339
emilio: I was going to say something related what Ian said. we could
add a switch but I'd also like to ignore the legend
emilio: If the use case for aligning to a legend comes up often,
where you're aligning text outside the fieldset with the
legend of the fieldset, which seems odd, we could look to
allow that
emilio: but seems farfetched
emilio: for most cases top alignment should do
zcorpan: We discussed whether there's a case where legends wouldn't
be aligned
zcorpan: if you have a fieldset with one line of text and another
when the legend is 2+ lines of text
zcorpan: those wouldn't be necessarily align
zcorpan: depending on what we decide
zcorpan: maybe I misunderstood
<astearns> no, I had the same idea
iank: That's a similar problem if you try to align a fieldset with a
legend and one without
Rossen: It sounds the obvious use case is that the first baseline of
content needs to be available
Rossen: we need to resolve to have first-line baseline based on the
content be available.
Rossen: The second question is whether we need to make the legend
baseline also available
emilio: I would propose to try resolving the default be the baseline
of the content
emilio: if there are use cases that can't be solved without the
baseline of the legend, work on what fantasai was talking
about, choosing the baseline box
Rossen: Seems to agree with the majority of the +1s and arguments made
<zcorpan> +1
Rossen: Objections?
fantasai: Defer to emeyer and jensimmons
emeyer: The proposed resolution is to default to first or last
baseline of the content?
emilio: Both baselines first and last would be baseline of the
content box
emeyer: Feels probably correct, I'll take a look at various cases to
confirm it's not a bad idea, but seems like the best
resolution
RESOLVED: Default first/last baselines to be those of the fieldset's
content
Received on Tuesday, 25 October 2022 22:38:28 UTC