- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:58:26 -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.
=========================================
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:
https://lists.w3.org/Archives/Public/www-style/2016May/0089.html
- After some discussion, there was mostly positive responses to
the proposal and a feeling that it would be a useful addition.
===== FULL MINUTES BELOW ======
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
now.
<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
was.
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
descendants.
Florian: In L2, add back match-parent and sort out cyclic
dependencies.
Florian: Do people agree that this simplifies things? Is it a good
idea?
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
columns.
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
elements.
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
rhythm.
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
amount.
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
BFC
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
flex?
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
lines.
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
grid.
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;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
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
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:59:31 UTC