W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part III: CSS Align [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:37:46 -0400
Message-ID: <CADhPm3uB+rxjgA9gFk_OdvuJKZ1q4vVRK1aBPte8Hq+DF2y2PA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC