- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Jan 2016 05:32:18 -0500
- To: www-style@w3.org
Round Display
-------------
- RESOLVED: Have the computed value for polar-angle keywords
resolve to an angle
- Several people expressed support for position:
relative/absolute/fixed/sticky enabling the polar-*
properties, but at least one implementor needed more time to
investigate so the group will return to the topic, hopefully
next week.
- The group needed BradK to be in the meeting to discuss the
removal of polar-origin in favor of his center proposal.
Accepting the alternate proposal for snap points
------------------------------------------------
- MaRakow just came back from vacation today, but promised the
group something for next week's telecon.
Grid
----
- RESOLVED: Accept the new text for grid and multi-col changing
the floor to a required amount. The new text is: "For
the purpose of finding the number of auto-repeated
tracks, the UA must floor the track size to a UA-
specified value to avoid division by zero. It is
suggested that this floor be ''1px'' or less."
- The potential options for how to drop repeated grid tracks with
auto-fit came down to:
1. Drop all empty columns
2. Drop empty columns from either end
3. Drop empty columns from end end.
- Several people were against 3 because it removed the
symmetry of the property.
- The group didn't have a preference between 1 and 2, so
decided to stay with 1 since that's what's in the spec now.
- RESOLVED: Change the initial value of align-content to stretch
May F2F
-------
- There's still no final location for the May F2F.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jan/0023.html
Present:
Rossen Atanassov
David Baron
Tantek Çelik
Dave Cramer
Alex Critchfield
Simon Fraser
Daniel Glazman
Tony Graham
Jihye Hong
Dael Jackson
Brian Kardell
Peter Linss
Edward O'Connor
Matt Rakow
Florian Rivoal
Alan Stearns
Ian Vollick
Greg Whitworth
Regrets:
Brad Kemper
Chris Lilley
Anton Prowse
François Remy
Lea Verou
Johannes Wilm
Scribe: dael
Round Display
=============
Computed value for polar-angle and polar-angle-reverse in the
animation using 2d rotation transform function
---------------------------------------------------------------------
astearns: Let's start.
astearns: Does anyone have anything to add to the agenda?
[silence]
astearns: I'll take that as a no.
<jihye> https://lists.w3.org/Archives/Public/www-style/2015Dec/0096.html
jihye: There is an unclear thing of polar-angle and
polar-angle-reverse value for transform function.
jihye: It needs to be decided if polar-angle value turns into an
angle or a keyword when determining the computed value of
transform.
jihye: In the last telecon fantasai said if the keyword remains as
a keyword I can't animate between it and another angle
value. For example animating between rotate polar-angle and
another rotate is impossible.
<jihye> If the keyword value remains as a keyword, you can't
animate between it and another angle value. For example,
animating between rotate: polar-angle and rotate: 0 isn't
possible. However, when polar-angle property animates, the
changes in it affect to the rotation function with the
keyword value. If the keyword value turns into an angle,
you can animate between it and a different angle. Thus you
can animate between rotate: polar-angle and rotate: 0 or
betwe[CUT]
jihye: If polar angle property animates, the keyword will not
track the changes in polar-angle property. Did I understand
right?
TabAtkins: I think so.
Florian: That's what we said, but I'm not clear why it wouldn't
track. If it computes to an angle and polar-angle is
changing, why is it not animating?
jihye: I was also curious about that. I wrote this (below) in the
mailing list with some questions.
<jihye> https://lists.w3.org/Archives/Public/www-style/2015Dec/0267.html
jihye: When the polar angle value remains as a keyword, animating
between it and another angle is impossible. Is this because
it can't be interpolated with another type of computed
value?
TabAtkins: That's right. But as long as the polar-angle isn't
determined by layout there's no reason why turning into
an angle at computed value time shouldn't track. That's
a new computed dependency, but that's the only
complication.
Florian: Did we get sidetracked along the way? Early on someone
said it wouldn't track both simultaneously. So if the
polar-angle animates really fast and you want to go
between that and an angle, it wouldn't take into account
that that and the origin would move between itself.
TabAtkins: That's the same as font-size and an n value. You can
have animations dependent on each other.
Florian: I think that was the early comment and then multiple
people misunderstood that to if you compute to an angle
then it won't track and that seems wrong. So we should
compute as an angle.
jihye: Yes, I agree with that.
TabAtkins: Yeah.
astearns: Alright, sounds like we have consensus.
RESOLVED: Have the computed value for polar-angle keywords resolve
to an angle
An idea about using polar positioning as a part of absolute
positioning
---------------------------------------------------------------------
astearns: The second item on the agenda, BradK asked to move to
next week because he can't attend. Is that okay?
jihye: Okay.
Rossen: Can we discuss without him and make the resolution pending
him?
astearns: Is there anyone who understands bradk's position well
enough to represent him?
jihye: There were several discussions about his idea with him and
Florian.
Florian: I think I can mostly, but there is one part where I don't
agree so I may not represent that one well, but I can try.
astearns: Do you want to? Do you think we can make progress
<jihye> * position: relative/absolute/fixed/sticky enables polar-*
properties. (polar-angle, polar-distance,
polar-origin, polar-anchor)
* If top/left/bottom/right is non-auto, polar-* properties
are ignored.
* polar-origin: auto is as same as polar-origin: 50% 50%
* polar-anchor: auto is as same as polar-anchor: 50% 50%
jihye: I think...I am curious about the other person's thought
about using polar-positioning in another positioning value.
The final position of the discussion was what I pasted
above.
jihye: We agreed to use polar-positioning when position is
relative, absolute, fixed, or sticky because there can be
several use cases that are outside of absolute polar. Are
there thoughts on this?
Florian: This would work...if you are in one of these absolute-ish
or relative-ish positioning mode and you set
polar-distance to non-auto you snap to polar-positioning,
but auto is the old way of doing things.
Florian: To me it seems useful.
Florian: Having the choice between absolute and fixed sounds nice.
Relative and sticky is nice too, though it's a different
beast.
Florian: Does anyone else have an opinion?
smfr: As an impl I want it something like relative so if you want
fixed or sticky it should be in a container. I don't like
snapping with a behavior that happens to trigger.
Florian: The coordinate system you use would have to be
rectangular or whatever. It's still the same positioning
if it's relative etc.
smfr: So you set polar, figure out the position, and position
relative to the containing block in the normal way?
Florian: Yes.
smfr: I have to think some more.
Florian: To put everything on the table, the second part of the
argument is we wouldn't need the polar-origin and drop it
in favor of center which positions to the center of the
element. center:center would be the same as polar-
origin, but it would also work for non-polar.
TabAtkins: We have centering random elements in the alignment.
Florian: That's my position, but what I said was BradK's.
Florian: His center positions things by the center. So aligned to
the vertical center and left side is hard now.
TabAtkins: But again, the alignment property would do that.
Florian: Would it?
TabAtkins: Yeah. You use justify or align: self. Center one, left
the other.
Florian: What you said aligns the left side to the left side.
Brad's proposal puts the *center* of the element at the
left side of the containing block.
TabAtkins: That seems less...until I see a use case I don't think
we need to optimize for making an element overflow.
Florian: I'd tend to agree.
Florian: I don't share his opinion so I can't argue it.
astearns: Other opinions on dealing with the auto values? The
first part on the discussion.
astearns: smfr, said you needed to think more. If you have time it
would be great to have you look on the list. If other
implementors have opinions, get to the list. We'll talk
next week with BradK
smfr: Sounds good
Accepting the alternate proposal for snap points
================================================
MaRakow: I'm not in the office yet, I've been on holiday for three
weeks. I'll have something to show next Wednesday
astearns: Is that acceptable to everyone?
TabAtkins: I'm not happy to wait an additional week since we've
already gone past where we want a decision, but there's
nothing else we can do so sure.
* fantasai notes that we have resolutions on the technical changes
already
<Florian> +1 to Tab
Rossen: I have a quick question to other browsers you're siting.
Who is blocked on this not being there?
TabAtkins: Everybody.
Rossen: That was to the other browsers.
TabAtkins: Well we're blocked.
Rossen: Webkit and Gecko?
dbaron: We shipped what was in the old spec when we didn't like it.
We're afraid to change until we're convinced it's stable
and others will change.
Rossen: That matches my understanding.
TabAtkins: That's why I'm frustrated. We had agreement two months
ago and we're waiting on someone doing the work. There
is non-interoperable content on the web. You can't use
snap points.
Rossen: I'm also unhappy. Let's put that aside. I'm trying to find
out what is the urgency and who is blocked most. There was
urgency voiced in Paris about the competing spec to be
finished and wrapped up by TPAC. At TPAC when we sampled
the same question and asked for the urgency, there wasn't
huge urgency by webkit or gecko. I'm not trying to
diminish what you said. That's why I'm going to them to
find out if they're blocked with devs waiting to finish or
will they start work when the spec is ready.
smfr: We shipped prefixed old spec. No one is working on snap
points now.
Rossen: That was my understanding from TPAC
TabAtkins: We're in a holding pattern with an implementation of
the new spec. As soon as the WG signs off we're ready
to go. Whatever we implement won't be interoperable.
Rossen: That's clear.
Rossen: There's a commitment from MaRakow that we'll have the new
spec next week.
TabAtkins: I want an explicit that we'll go to this next week. We
agreed on the details. I don't want to show up next
Wednesday and need time to review. That happened for
two years.
MaRakow: Two years ago Google didn't want it and wasn't interested.
I'm not sympathetic. I understand it needs to be done
soon. I want it done. It will be ready. I wanted it done
two years ago.
Florian: One thing I want to clarify about a danger to not doing
it fast, it's currently not interoperable...is that good
because there cannot be any web content using it or are
we seeing an body of web content building up, and locking
us into one of the variants of the old solution?
fantasai: There's a risk, there always is.
astearns: Next week we'll get out of the holding pattern. We
should go on.
Grid Topics
===========
Flooring track sizes at a UA-defined minimum for the purpose of
finding the number of repetitions in auto-fill cases
---------------------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0157.html
astearns: This is a hold over from last year's meeting.
astearns: Is it TabAtkins or fantasai that wants this?
TabAtkins: This was applying a min-size to auto-repeat. Does
anything need to be decided?
Rossen: I don't recall us resolving.
TabAtkins: Okay. auto-repeat has a space to fill, you give it a
track list, and it tries to fill. If it's 0px you can
end up with infinite.
TabAtkins: So we now have a UA defined minimum, we recommend 1px
because it's nice and small. And we need to apply that
to multi-col because it has the same problem.
TabAtkins: Unless there's an alternative, we can resolve on this.
Rossen: I'm okay with the change. My only ask is we make 1px
clearly that in the spec so it's easier to text instead of
it being suggested and everyone does their thing.
TabAtkins: Okay.
RESOLVED: Accept the new text for grid and multi-col changing the
floor to a required amount. The new text is: "For the
purpose of finding the number of auto-repeated tracks,
the UA must floor the track size to a UA-specified value
to avoid division by zero. It is suggested that this
floor be ''1px'' or less."
fantasai: The current minimum in Mozilla is 1/60 px.
Rossen: That's why I brought it up.
astearns: Who will change multicol?
Florian: I will.
TabAtkins: I will.
Florian: I'll leave it to TabAtkins
Dropping empty repeated tracks
------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Dec/0155.html
TabAtkins: So the auto-fit value repeats a bunch and only uses as
many as you need. It's based on some use cases where
you want the grid to not be the full size with lots of
empty space. The definition of an empty track is clear.
But where do we drop from?
TabAtkins: Currently it's just the end of the list.
fantasai: I think we currently drop all the empty tracks. Mats
asked about only dropping end, not middle.
Rossen: They layout result from both will be identical.
TabAtkins: No.
TabAtkins: If you say you're repeating a 50px track and only have
something in 1 and 3. If you drop the last you'll have
an empty.
Rossen: Correct.
Rossen: The two things that stand out is 1) having the space
repeater where only non-empty are entered would make
having a good OM later more difficult if we're not keeping
the repetition. 2) keeping the pattern of repetition is
more predictable and it's easier to signal to content
authors you're doing something unexpected.
TabAtkins: We dropped repetition patterns so that doesn't matter
for this case.
astearns: I like the characteristic of having a stable layout as
you add or remove things from a grid template like this.
Having things collapse because you removed an item is
weird.
TabAtkins: There's another value that doesn't drop anything at the
end of placement.
TabAtkins: Temporally in the algorithm.
fantasai: So what we have is auto-fill and you can choose one size
that will repeat to fill space. You can keep as many
columns as fit or drop any columns empty after we've
filled. So you have a catalog and you're trying to fit
as many columns. But you only have 2 items and there's
room for 10 you drop the others to center.
fantasai: We don't have concrete cases for leaving gaps in the
middle, but that's what we're trying to answer. Instead
of automatically created tracks, if you place things and
have empty tracks, do you drop them? So can anyone come
up with a reason to leave a track in the middle empty?
fantasai: If there's a reason we can decide if we should drop them.
If there isn't a reason to want them, we have an
arbitrary decision. A use case would help us make a
useful decision.
<gregwhitworth> http://threesjs.com/ imagine these are using
repeat for creating the tracks
astearns: gregwhitworth posted a link to a game grid, but I'm not
sure you would use a repeat there. I assume it's a 4x4
grid.
fantasai: It wouldn't be auto repeating.
Rossen: Is the dropping specify that it's an empty column across
all rows?
fantasai: Yes. You can't drop a track if there's stuff in it.
<fantasai> spec link - https://drafts.csswg.org/css-grid/#repeat-notation
astearns: I have this grid and I've placed an item in track 1 and
track 3 and I get a two track thing because the center
collapsed.
astearns: I would prefer not dropping empty in the middle because
I've defined that this is track 3.
Rossen: That's why I brought up the OM. If you're using the tracks
as identifies you don't have the second and that's off.
fantasai: If you have tracks 2 and 4 with stuff, you would drop
track 1 and 5?
Rossen: Just 5.
fantasai: I think plinss brought up a desire to have it symmetric
and just 5 is asymmetric.
astearns: I'm suggesting we take the author's intent. I asked for
things in track 2 and 4 so I'm expecting 4 tracks.
fantasai: But you...you wouldn't use auto repeat if you knew how
much space. So we have a conflict between the obvious
which is only drop the end and the guiding principle of
symmetry.
Florian: Numbers aren't symmetric.
fantasai: The numbering system can work from both directions. The
system we have for positioning is very symmetric and
that's a good thing.
fantasai: Sticking with that is better than guessing author intent.
I think keeping the symmetry is stronger. But I don't
have an opinion on dropping middle.
TabAtkins: The use case for this isn't positioning things
explicitly. This is for auto-placement of a bunch of
items and you just want to have it not be extra big.
astearns: And you could have voids in the middle?
TabAtkins: There should not be. I have to really think if there
are things in the algorithm that could lead to that.
This is really defining error behavior.
fantasai: The author could have decided to use auto-fill and
explicit placement.
TabAtkins: You're using the grid wrong in that case.
Rossen: That's why I'd prefer predictability.
fantasai: If you want to not hide anything you wouldn't use this
keyword. This is to drop extra columns that aren't being
used so you can center if you don't have enough columns
to fill the space.
<fantasai> 'auto-fill' will not drop columns
<fantasai> 'auto-fit' will drop empty columns so that you can
align the remainder
TabAtkins: This is anti-predictable because it's meant to respond
to content. You can't predict the number of columns in
the general case.
TabAtkins: Even if we just drop on the end, your track positioned
with negatives will show up more unpredictably.
fantasai: This is after placement. Nothing will change.
fantasai: So the options are:
<fantasai> 1. Drop all empty columns
<fantasai> 2. Drop empty columns from either end
<fantasai> 3. Drop empty columns from end end.
fantasai: I'm somewhat against 3, but okay with 1 or 2.
astearns: 2 is both ends?
fantasai: Yeah.
astearns: I don't have a strong opinion.
astearns: If we're going to drop columns at all, maybe go with #1
Rossen: Or make it a feature of the feature.
astearns: No switches!
astearns: If this is an anti-predictable feature, maybe several.
fantasai: There's a don't drop empty columns or drop empty columns
and you choose that up front.
Rossen: To resonate dholbert, from an implementor point of view if
you've implemented dropping any columns, implementing
dropping the end later should be trivial.
Rossen: I'm okay going the most restrictive and going where
feedback suggests.
astearns: Other opinions?
fantasai: Let me pull up the e-mail. I think Mats preferred not
the middle.
Rossen: Is that because the extra lines of code?
fantasai: No, I think he implemented dropping all the tracks. And
dholbert was expecting on the end.
Rossen: Okay, sorry.
fantasai: Okay.
Rossen: Do we need a resolution?
fantasai: I don't have a preference. I can try and collect more
feedback. Otherwise as a WG we don't have a preference
between 1 and 2
astearns: I prefer choosing one or the other.
TabAtkins: You prefer someone to have a preference.
astearns: Yes.
TabAtkins: So let's resolve on 1.
astearns: I'm happy enough to do that now.
astearns: fantasai do you want more feedback?
fantasai: The spec currently has option 1. I'll see if someone
comes up with a reason to go with 2. We don't have a
good use case.
astearns: So I guess we don't need a resolution.
Changing initial value of 'align-content' for grid containers to
match Flexbox
---------------------------------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2015Oct/0026.html
TabAtkins: Right now if you have a grid that's smaller than the
container it defaults to start, start. Flexbox defaults
to stretch. Javier in Chrome thinks this inconsistency
odd and would like both to have stretch.
TabAtkins: Stretch only effects auto-sides grid tracks, so that's
the only change.
fantasai: And if you don't have a container fixed to be larger you
won't have an effect. So auto-size grid containers don't
have an effect.
TabAtkins: So this effects grid containers set larger than grid
inside and the grid has at least one auto-track
fantasai: I'm in favor of consistency. In the past there wasn't a
way to handle stretch in the past, but there is now.
<astearns> +1 for consistency
TabAtkins: The original decision wasn't intentional exclude, it
was because we couldn't. Does anyone object to the
consistency change?
Rossen: Sounds okay.
RESOLVED: Change the initial value of align-content to stretch
May F2F
=======
astearns: That's the end of the agenda.
Rossen: Did we ever settle the May F2F location?
astearns: No.
Rossen: I remember we decided west coast, but nothing more.
plinss: I have an inquiry to see if I can host, but no reply.
Rossen: We should solve that by end of month.
Florian: So we said west coast, even just CA. Is it HP or someone
else, or just HP possible to host?
Rossen: Did we ever settle on CA or all of west coast?
Florian: I think so, but may be wrong.
Rossen: So I'll let the people from southern west coast explore
options.
astearns: So hopefully we'll hear something soon.
Rossen: One more quick item. I e-mailed the list from TPAC about
specs we agreed to update. Please give that a look and
update items as you find time
astearns: And if we don't have an update soon, we'll bug people.
astearns: Thanks everyone for calling in, we'll talk next week.
Received on Thursday, 7 January 2016 10:33:17 UTC