W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-12 Part III: Text Breakout - Line Grid, Block Step Sizing [css-line-grid] [css-rhythm]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:58:26 -0500
Message-ID: <CADhPm3uLnKx-m55J+9JUDsVGcM9NWPUVpbp7yCfzCvBsr9rrVg@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.

Text Track

Line Grid

  - Florian asked for feedback on finding a way to get momentum on
      the spec. He suggested adding an auto value on line-grid, but
      there was concern that's too limiting to be useful.
  - Overall simplification was then discussed to get momentum, but
      several browsers said that that would not cause this to move
      further forward on their roadmap.
  - fremy proposed a within-BFC line grid declaration that several
      browser expressed an interest in, so he was actioned to write
      up his proposal.
  - RESOLVED: line-height-step affects line grid

Block step sizing

  - fantasai introduced her proposal to add a block step sizing
      property to CSS Rhythm:
  - After some discussion, there was mostly positive responses to
      the proposal and a feeling that it would be a useful addition.


Agenda: https://wiki.csswg.org/planning/seattle-2017
Note: The group split the morning of the 12 January on two
      tracks: FX and Text.

Scribe: fantasai

Text Track

Line Grid

  Florian: I think one major reason line grid hasn't made progress
           is complexity.
  Florian: Could be interesting to try to find a simpler L1.
  Florian: Feedback from implementers was that this is too large to
           consider, given it's not high enough priority.
  Florian: Would like to find a subset that can grow into what it is
  <dbaron> I remember having a discussion with fantasai about
           something else that was difficult about line grid, but
           that actually had a bunch of aspects in common with
           things needed for other specifications, and seemed like
           it would be doable... but I don't remember what the issue
  Florian: What I understand to be the worst part of line grid
  Florian: is that it can make size depend on position and position
           depend on size.
  Florian: For example, if you have a vertical flexbox
  Florian: the flexbox establishes a line grid, and flex items snap
           to it.
  Florian: Depending where the flex items are, will snap
           differently, which may then affect its size, which they
           affects its position.
  Florian: Line grid makes the position of something influence its
           intrinsic size, which makes it tricky.
  Florian: Was thinking to break that loop for L1.

  Florian: First is add as initial value to line-grid property an
           'auto' keyword,
  Florian: Which does the same as match-parent on most elements and
           same as create on BFC
  Florian: then drop the match-parent value.
  Florian: Enforce not allowing line grid to pass through BFC to
  Florian: In L2, add back match-parent and sort out cyclic
  Florian: Do people agree that this simplifies things? Is it a good

  astearns: I think it does simplifies things, but not sure that
            what it leaves is interesting enough to implement.
  astearns: What you lose is ability to align baselines between
  Florian: If you do columns with actual multicol, you don't,
           because each column starts at the same place.
  astearns: Columns in page layout.
  astearns: Different blocks in a page layout, I mean.
  fantasai: Simple case of main content and sidebar, can't handle it.
  astearns: If you get their tops to align perfectly, then, you
            could maybe make that work?

  astearns: But also depends on nesting formatting contexts.
  astearns: Currently spec tries to limit the interaction between
            positioning and sizing by saying that the effect on
            sizing of shifting the blocks position can only be a
            certain amount which is less than one line grid height.
  astearns: And its done this way, there's an algorithm for saying,
            you size a thing as if its position would fall correctly
            on the grid.
  astearns: Then you find out by how much you're off the grid, and
            then you add that much size at a particular place.
  astearns: So that when you are positioned you are sized correctly.
  astearns: It's not a loop but an adjustment you have to make.

  Florian: Another variant was instead of match-parent value
           dropped, make it at-risk
  Florian: ....
  Florian: Leaves it up to UA.
  Florian: Even if you implement everything, I think 'auto' is useful
  fantasai: 'auto' is unpredictable, from an author POV, because BFC
            is unpredictable, from author POV.
  astearns: Making the default value whatever it is create a line
            grid, makes line grid an opt-in thing.
  astearns: Participating in a parent or an ancestor's line grid is
            an opt-in thing.
  astearns: Makes it much more difficult to find all the places
            where you have to set match-parent.
  fantasai: You are not making the system easy to understand if
            you're making it depend on BFC vs regular block.
  Florian: Use a * selector.
  fantasai: That's not a very nice way to do things.
  astearns: Maybe do auto, but instead of match-parent use named
            line grid
  astearns: ... no I'm wrong.

  fantasai: I don't think simplifying things down here is a good
            idea. I think having a compelling, coherent solution to
            a set of compelling use cases would be a better approach
            to soliciting interest.
  Florian: Implementers cite complexity.
  myles: We have described use cases that would be omitted from line
         grid if this were accepted
  myles: And those are some important use case that we see people
         trying to solve
  myles: Therefore if this proposal were accepted, it would be even
         lower priority than it is now.
  fremy: Proposal doesn't say you can't implement everything.
  Florian: Implementers weren't interest in the proposal
  myles: This proposal would make us less interested.
  astearns: fremy was saying that you could ignore the level 1 cut
  astearns: My concern is that this L1 proposal would make L2 less
            easy to use.

  Florian: I'm not hearing overwhelming consensus over the idea, so
           willing to drop it.
  astearns: I'm perfectly happy to define a simplification, as long
            as it's something we actually want.
  fantasai: So sitting around and waiting might be more productive
            than trying to find a simplification.
  Florian: Is it useful to try to find a simplification, from
           implementer's point of view?
  eae: Not from our PoV.
  myles: Not from our PoV.
  fremy: For us, depends on the time scale. We're not going to ship
         any of this within the next year or two.
  fremy: Even later, interdependency of size and position is a
         problem for us.
  fremy: Right now, we would only consider if it's a web-compat issue
  fremy: Making a simplification might change things.
  myles: Sounds like we should wait a year or two
  fremy: If other vendors are going to implement, get critical mass,
         then we'll look into it.
  astearns: I appreciate the attempt, and if someone has a good idea
            of a good simplification, then would consider it. But
            probably not worth spending time on it right now.

  fremy: Having line grid within BFC is better than not at all
  fremy: You would make it a property of the grid declaration, then
         don't need to declare match-parent on individual other
  astearns: I could see that possibly working from impl side. Be
            concerned about the author story, to explain why grid is
            working here and not other places
  astearns: Also utility of the feature is limited if it can't go
            through formatting contexts, then only get very local
  astearns: Could you add an issue to the spec suggesting this
            grid-until-fc idea?
  astearns: Two people in the room who are implementers expressed
            interest in it.
  iank: Might be able to go through FCs, but a bunch of questions
        that we'd need to sort through.
  iank: Obviously this doesn't cross writing modes.
  Florian: We already have that limitation.
  iank: I'm semi-confident we could do it within an FC
  iank: Less confident about crossing FCs.

  astearns: Please add an issue, I'll think through it.
  astearns: Also, I described algo on limiting effects on sizing.
  astearns: Please review and see if it's OK.
  astearns: More feedback from more implementers would help.

  ACTION: fremy to propose within-BFC line grid declaration
  <trackbot> Created ACTION-820

  Florian: Separate line grid proposal -- since we just adopted
           line-height-step thing
  Florian: Should the line grid be established by the stepped height.
  fantasai: Yes.
  astearns: Open an issue and I'll make the change.

  RESOLVED: line-height-step affects line grid

  Florian: Just makes sure that when you turn both on, they work
           together rather than interfering.

  astearns: Any other discussion items on line grid?
  astearns: Out of agenda items for the morning.

Block step sizing

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0089.html
  SteveZ: How does this interact with margin collapsing?
  fantasai: I think what it would mean is that the margin
            contributed by this element is increased.
  fantasai: You would have to increase the collapsed margin by this
  SteveZ: If another collapsed margin is larger...
  iank: You'd just pull the block down.
  astearns: Should stepped things not collapse margins?
  fantasai: The plan here was to turn anything that's step-sized a
  fantasai: since that would avoid the float complexities.
  iank: You'd still have to deal with clearance.
  fantasai: The goal is to have the margin box of this element to be
            a multiple of the step size
  fantasai: defining how margin collapsing works is definitely going
            to be an issue we need to tackle.
  iank: I think we only want to allow increasing the size of the
        border box, not increasing the margins.
  fremy: You get a problem with border images.
  SteveZ: Or change the aspect ratio of an image.
  SteveZ: Seems like we'd really like it to be in the margin box, if
          we can define how it behaves.
  fantasai: You could, in terms of implementation strategy, treat it
            as a kind of outer invisible border, so it's still
            inside the box object's rect geometry.
  Florian: ...
  SteveZ: My concern is that if, in margin collapsing, we have a box
          which has been size-adjusted.
  SteveZ: If its margin wins, then you're reasonably certain that
          the alignment is kept.
  SteveZ: If the other margin wins, then it's not as obvious to me
          that the margin says.
  Florian: You could adjust the collapsed margin.

  fantasai: I have a simpler idea. How about we ignored the result
            of the collapsed margin?
  fantasai: Just step-size the margin box of the element as
            specified, ignoring other margins.
  fantasai: Collapsing margins may result in throwing off the
            rhythm--but that's if you specify *other* margins
            without step-sizing them.
  fremy: What about float clearance?
  fantasai: I think we should consider that out of scope. We're step
            sizing this box, not step sizing the whole layout.
  Florian: This isn't line grid.
  fantasai: Right. If you step size the float, and you step size the
            things wrapping around the float, then it'll all line up.
  fantasai: But step-sizing clearance before an element because you
            decided to stepwise size that element, that seems like a
            bad thing to try to do here.
  fantasai: Step-sizing would allow you to add space to the margin
            or to the padding, but it should be looking at the
            element locally, so it only affects that element's
            margin or that element's padding. The result then
            interacts with margin collapsing, as if it were the
            specified margin size.

  fremy: What about just always adding the space to the bottom?
  Florian: It's configurable.
  dauwhe: That's rather less useful. In fact you most often want it
          at the top.

  astearns: Other comments on proposal?
  fremy: What would you do on a flex item?
  fremy: Do you increase the margin before you flex? or after you
  fantasai: I think that you would want to do the step sizing prior
            to flexing
  fantasai: but I'm not sure.
  astearns: I think it's just like sizing.
  astearns: It's a height that goes into the flex calculation.
  astearns: Your final height might not be a step height. Flex wins.
  astearns: Grid positioning wins.
  astearns: This is just an input into layout calculation.
  fantasai: Another way to look at this, which would have the
            opposite effect, is to treat it the as min/max clamping
            from the min/max-width/height properties
  fantasai: And we already know how those interact.

  fantasai: Probably we should look at use cases here.
  fantasai: In any case, the most critical piece here is getting it
            to work for block-level elements.
  fantasai: We can start by defining it for those, and then add in
            for other layout modes as we figure them out.
  fantasai: Kinda like we've been doing for box alignment.
  fremy: I like this idea.

  SteveZ: Question on alignment, if I have two cell table, one row,
          two columns.
  SteveZ: 1st column has a heading in it, 2nd column doesn't. I do
          baseline alignment. I've broken the rhythm.
  SteveZ: I haven't got control of being able to push that first
          line of text onto the line height, I can put space above/
          below it, but text will land where it lands.
  SteveZ: Is there a need for distributing space above and below so
          that baseline lands on the line grid?
  Florian: I think that's what you get when you define interaction
           of this and line grid.
  SteveZ: Agree it doesn't get aligned, don't need to solve that
          problem yet.
  SteveZ: Looking at alternative that distributes space above and
          below in a way that aligns to the baseline grid.
  Florian: I want to solve that, but it would be along the line grid
  SteveZ: Stick an issue in the document says, is it worth solving
          this problem?
  fantasai: The goal of this spec is to get the margin box of the
            element step-sized. The contents of the element lay out
            with respect to the resulting size, but don't interact
            with anything outside.
  fantasai: There are many use cases where that is what you want.
  SteveZ: I want to add a space distribution option that lets you
          align the baseline of the content to a multiple of the
  astearns: That's a different feature.
  Florian: I would try to use the line grid to solve that problem.
  fantasai: This is just a black box. you don't know the content
            inside it, just its size.
  SteveZ: ....
  fantasai: You're not caring about the baseline there, you're
            caring about the position of the edges of the line box.
  SteveZ: Case is you want your headings, let's say they are 2lh
          high, I'd like them ideally to align with the same rhythm
          as the other thing.
  SteveZ: But that doesn't immediately fall out..
  Florian: I don't think it does, and you solve it with the line

  Bert: Question for clarification...
  Bert: block-adjust-insert: margin | padding
  Bert: So the goal is to size the margin box or the padding box?
  fantasai: I think the goal is the step-size the margin box, and it
            says whether you do that by inserting space int the
            margin area (invisible) or padding area (increases
            border-box height).
  Bert: What if you want to step-size the border box?
  Florian: Use margins that are a multiple of the step size?
  fantasai: Could be something else to consider.
  SteveZ: ...
  Florian: Step sizing alone to achieve vertical rhythm is fiddly.

  astearns: Other comments on rhythm? or take a break?
  astearns: OK, calling a break

  <br type=lunch><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
        <td style="width: 55px; padding-top: 13px;"><a
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Tuesday, 14 February 2017 01:59:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC