- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 27 Aug 2017 14:56:20 -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.
=========================================
Media Queries 4
---------------
- RESOLVED: Florian to move the reference to informative, and
provide specification text describing the color space
(color values, white points, etc)
- RESOLVED: Take Media Queries 4 to CR.
Additive CSS
------------
- birtles outlined his proposal (explained here:
https://github.com/w3c/csswg-drafts/issues/1594)
for additive CSS:
- The proposal was based on how Web Animations are working in
the web now.
- Additive CSS would allow for multiple animations to be
applied simultaneously.
- The order to add things would come from the 'animation-name'
property where anything that can't be added would fall
back to replace.
- This proposal also had a less defined section that would
introduce !add to allow other sections of CSS to be added,
such as filters.
- There were several people who that this was really two
proposals, not just one, and that they may need to be
separated.
- RESOLVED: No concerns wrt shipping Web Animations
- RESOLVED: CSSWG is interested in working on additive cascade
proposals.
CSS Alignment
-------------
- RESOLVED: First baseline of multicol is first baseline of first
col, last baseline synthesized as described above (
first baseline = first line of first column; for last
baseline, synthesize based on bottom margin edge).
(Issue #1572)
- RESOLVED: Slash must be used to separate main value and fallback
value in shorthand and longhands alignment properties.
(Issue #1002)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/paris-2017#topics
Scribe: dino
Media Queries 4
===============
Color spaces in the color-gamut media query
-------------------------------------------
Florian: Here's the D.O.C
https://drafts.csswg.org/mediaqueries-4/issues-wd-2016-01-26
Florian: We should go to CR but.... we have one normative dep that
isn't available for free.
Florian: The color-gamut media query references some color spaces
that are specifications not available for free.
tantek: Is this new?
Florian: It's been in a few drafts, but never a CR.
<tantek> FYI: https://www.w3.org/2013/09/normative-references
glazou: Is the problem even relevant? The decision should be about
whether or not it is a stable standard.
Bert: The W3C does not like it, but there is nothing prohibited in
this case.
Florian: To make it slightly less painful, it's not absolutely
necessary. The query is about approximation, not the
absolute colors.
tantek: We have a policy, I linked it.
tantek: I think this policy has been used to point out transition
issues
tantek: it mentions stability, and royalty-free-ness of the spec.
tantek: Whether or not the spec is freely available is mentioned
too.
glazou: The ISO specs are also in this area. Not available for
free.
tantek: We produce our own versions of it.
tantek: This being available RF is a big deal.
SimonSapin: We are just referencing by name.
Florian: We need very little of the actual details to implement
this.
tantek: Another approach would be to provide a small subset
ourselves
tantek: the way we did with ISO date formats.
Florian: If any other spec needs to reference it, they'll need
more details that what the media queries does.
tantek: If we need to get rid of it, we should inline it.
glazou: This might be forbidden.
glazou: Also, this is not the right place to discuss it - we need
the Director to decide.
[discussion about whether or not to point this out in a transition]
Florian: We would not need to copy&paste a large section of the
specification
Florian: e.g. we could just copy the color points, which gives an
idea of the size of the space
<tantek> no one is advocating copy/paste - that's a strawman
tantek: no, you have to rewrite it in your own words
Florian: I think we can do this.
tantek: Leave it as an informative reference.
glazou: Make sure the referenced spec allows to quote an extract.
<tantek> no don't bother quoting an extract either
astearns: I think that all we need is to put the three points in,
and make the reference informative.
Florian: Do we think this is enough?
myles: It's a fuzzy match, so it doesn't need to be exact.
tantek: We can get this feedback during CR if it isn't accurate
enough.
RESOLVED: Florian to move the reference to informative, and
provide specification text describing the color space
(color values, white points, etc)
Publication
-----------
astearns: There may be one more issue in the D.O.C
astearns: One item should be deferred.
Florian: Issue 7 in the D.O.C is marked as invalid. It could
potentially be marked as out of scope or deferred.
gsnedders: "some spec should probably solve this at some point" -
doesn't need to be MQ
Rossen: any objections to taking Media Queries to CR?
[none]
RESOLVED: Take Media Queries 4 to CR.
Florian: We are going to need tests for syntax. Some tests are
going to be hard to write.
dino: This is the problem with browser-testing MQ
dino: You have to write internal code to test the media query by
faking it
dino: But you're only testing half the system that way
Florian: we previously tested only the syntax
Additive CSS
============
Scribe: fantasai
<birtles> https://github.com/w3c/csswg-drafts/issues/1594
birtles: This issue covers everything I want to say.
birtles: Want to introduce idea of additive CSS
birtles: Figure out if we want to do this soon or not
birtles: We have something like this in Animations, wanted to see
if we should pursue in static CSS also
Additive Animations
-------------------
birtles: Start off with additive animation
birtles: then static additive CSS
birtles: Normally when you have animations in CSS
birtles: basically you can only ever have one animation affecting
the same property at the same time
birtles: This demo here has animations spin and swell
birtles: when I apply the both
birtles: you can see only the swell animation is taking effect
<birtles> http://slides.com/birtles/browser-animation-2017-2#/3/11
birtles: This can be due to the nature of the cascade, only one
animation declaration will win
birtles: But even when you specify two animations in a single
declarations
birtles: then the declarations in the keyframes could override
each other.
birtles: Problem in animations.
birtles: There's a means for solving that which comes from SMIL
birtles: and is in Web Animations
birtles: where you define the properties as being additive.
[birtles shows demo with Web Animations that shows spinning and
growing at the same time]
glazou: Do you put composite=add on both of them?
birtles: Only the top one.
birtles: If you declare an animation as additive, then it adds to
underlying unanimated style, or adds to underlying
animations
birtles: wherever in the chain doesn't say add, clobbers earlier
declarations.
glazou: animate(composite=add) that's ok
glazou: but for properties...
glazou: parsing is not done yet?
birtles: That feature is defined in Web Animations, implemented
(but not shipping) in Chrome & Firefox
birtles: Property for CSS Animations 2 to give same feature.
birtles: How does it actually work?
birtles: Different animations types, define what it means to add
animations
birtles: then need to define order, since not operations are
commutative
birtles: and also need to know which to exclude.
birtles: Web Animations there's a defined order
birtles: but for CSS Animations the order of the animations comes
from the 'animation-name' property.
Florian: If you're trying to add things that are not additive,
what happens?
birtles: Just as with interpolation, there are some types are not
interpolable and we fall back to discrete.
birtles: For types we can't add, we fall back to replace.
Florian: Is this stable? Are there things that we could add in the
future but can't right now?
Florian: e.g. auto + <length>
birtles: Yes, and there is this problem also with interpolation.
birtles: Our hope with interpolation is that filling in gaps won't
break content, we don't know but we hope
birtles: so in this case also hoping.
fantasai: I think switching from replace to add is more likely to
break that switching from discrete to gradual
interpolation.
Florian: In JS, could throw an exception, but not in CSS.
birtles: Amelia had a concern about defining addition.
birtles: There are different ways to add things
birtles: e.g. blur(2px) + blur(5px)
birtles: is it blur(2px) blur(5px) (sequence) or blur(7px).
birtles: Web Animations has two different modes of addition
birtles: add and accumulate (corresponding to above, respectively).
birtles: For most types they're the same operation, but for list
types are different.
birtles: I think Amelia was concerned because accumulation in SMIL
is used in repetition
birtles: but here it's just another type of add.
melanierichards: You mentioned that if you get to something that
doesn't add, does it replace all the values added
up below it
melanierichards: [gives an example]
birtles: Overrides sum up to that point.
birtles: Add means "add myself to what's beneath me"
birtles: You have a stack with A at the top and D at the bottom
birtles: A and B are additive, C and D are not
[discussion of what ordering means]
dino: Don't say it's a stack. Everything is a list. The last one
wins
<dbaron> so this would be like animation-name: D, C, B, A.
birtles: The result of that would be A + B+ C
dino: And if A wasn't additive, then result would be A
birtles: And if all additive, then you get A+ B+ C+ D+ underlying
style
Florian: When you're switching into another style, add to the top
of the stack, which can override those beneath it
birtles: This proposal suggesting that if we expose in regular
standard CSS, then the ordering comes from the Cascade
birtles: if you have something of higher specificity, takes
precedence.
dbaron: There are two different mechanisms proposed here
birtles: Why have this to begin with?
birtles: The most common use of additive animation is for
combining transform animations
birtles: to some degree can already do that with separate
transform property in L2, where we have
translate+rotate+scale properties
birtles: Solves a number of use cases, but doesn't solve all of
them.
birtles: If you wanted independent animations of the same
operation, doesn't allow you to add those
birtles: Doesn't help with other things like filters.
birtles: Any cases where separate transformations are not split
out enough in our syntax.
birtles: The other way to solve these problems currently is to add
another <div> wrapper element. Not very appealing when
you have a lot of transforms.
birtles: So that's a summary of additive animation
birtles: It's in Web Animations spec atm because the scope of Web
Animations was to cover all the features of CSS
Animations, [?] Animations, and SMIL
birtles: And SMIL already has this feature.
Additive Cascade
----------------
birtles: My next proposal is a straw man for providing the same
functionality in static contexts for regular CSS, not
just animations
birtles: Here's an example of combining filters
[birtles shows off examples in the issue]
birtles: Some potential use cases.
birtles: Proposal is to add a !add to the end of the declaration.
birtles: Ordering is given by the cascade.
birtles: Not a fully fleshed-out proposal, just a rough idea.
birtles: Last question is whether to ship additive animations as
specced or wait to line them up with these other features.
glazou: First, about your use case, about the filter property.
glazou: This is easily doable with variables.
glazou: Not for an unlimited number of classes or inputs, but if
you know the scope of the styles you can get fairly doable
with variables.
glazou: Using !add would allow some cases.
glazou: Next, !important, how does that interact with this?
birtles: !important continues to affect where it appears in the
cascade.
dbaron: I've wanted to have additive cascade for a long time, just
didn't have a good syntax for it.
dbaron: Normal cascading order is that you have a sorted set of
declarations and the last declaration wins.
dbaron: The cascade just produces a sorted list of declarations.
With !add, instead of taking just the highest one for a
property, you'd take all of the highest ones down to the
highest that doesn't have !add.
glazou: What would happen to APIs that climb the cascade and find
*the* rule that wins?
birtles: Which APIs?
glazou: Inspectors in browsers.
birtles: Any Web-facing APIs affected?
fremy: There's a depreciated API in Chrome.
glazou: So browsers internally will have to update something, so
OK but be careful.
birtles: Inspector also shows which rules were clobbered.
fantasai: So you'd have an ordered set of declarations that win,
not just one.
Florian: If you getComputedStyle or some similar thing that gives
you the computed value
Florian: when something has been added
Florian: do you return calc()? what do you do?
birtles: Depends on the case
birtles: similar to interpolation
birtles: e.g. adding % and length, get a calc.
dbaron: A lot of these are lists, which would append items.
astearns: Do you get !add in the computed value?
<fantasai> No
dbaron: There's always a lowest value.
astearns: Might have !add.
dbaron: Then there's nothing to add to.
fremy: There are two different proposal in this proposal.
fremy: There's list-accumulating behavior, which I and Tab have
been discussing.
fremy: This is reasonable to add to browsers, and solves most of
the use cases
fremy: There's another proposal for things like auto + 50px
fremy: That's a different proposal.
fremy: I think these are two very different proposals.
dbaron: This is one of the things I wanted to raise as well.
fremy: At least in this WG there are ppl working on list things, I
think it's easier to get there.
fremy: Trying to transform all properties into this kind of list
thing isn't something that we are ready to do yet.
astearns: Showing that we might want to go there is useful though.
birtles: This is implemented in Gecko, Blink, Servo, for more than
just these types.
birtles: The ability to add different CSS types.
TabAtkins: In Web Animations.
fremy: I would be curious to see test cases.
fremy: Still, should be mentioned they are two different things.
fremy: Another thing I dislike !add is that it's impossible to
redefine a value
fremy: e.g. you have filter: blur(val1) ??(val2).
fremy: You can add to the list, but you can't alter previous
values in the list.
<astearns> I thought "filter: blur(val) !important;" would override
<fantasai> astearns, yes it would
Florian: You can always wipe out the entire list.
TabAtkins: At that point, you should use variables.
TabAtkins: Variables allow coordinated substitution.
TabAtkins: Uncoordinated addition is what we have to solve here.
fremy: Other concern is that ordering matters, e.g. transform +
rotate and rotate + transform are not the same
fremy: It's a problem with web animations atm.
fremy: We have this problem with people making websites where
everybody is screaming the highest z-index.
birtles: For Web Animations there's no number.
fremy: People want to control the order, and !add will follow the
cascade order.
fremy: I think for lists, there are better ways to approach this
problem with more control.
fremy: Plain !add for list is not good enough.
fremy: When you are programming, used to being able to modify
values and that's something not there, and I think it's
really important.
astearns: Seems to me that you could fiddle with selector
specificity.
fremy: Specificity isn't always correlated with priority.
dbaron: Animations are one of the more complicated cases.
dbaron: There are a bunch of other list-valued properties where
you really want to combine.
dbaron: E.g. for counter properties, generally would prefer to
have declarations combine, ordering doesn't matter.
fantasai: Stuff in text decoration also (text-decoration-skip)
TabAtkins: A lot of properties are sets, not lists, order doesn't
matter.
fremy: My proposal would be to use an array syntax
fremy: And you could put a number as the argument, or a name.
[fremy writes some declarations
transform: translate(0px, 0px)
transform[zoom]: scale(1.1);
transform[rotate]: rotate(180deg)
transform[hover:100]: scale(1.0) translate(0px, 0px);
transition[]: transform[hover:100] 0.5s eas-in
]
birtles: We already have separate properties for rotate and zoom
in Animations L2.
Rossen: So your feedback is there's no way to have selection and
authoring of the list after initial declaration.
Rossen: Anything else?
fremy: Also that cascading order is not always the order you want
to concatenate.
fremy: There's also the issue of coordination between frameworks
fremy: If there's no way to coordinate other than defining /
redefining variables, then they can't coordinate.
fremy: You can't solve that problem with variables.
dbaron: Few comments.
dbaron: One is that there are two separate pieces to birtles'
proposal.
dbaron: I see these as independent
dbaron: I see reasonable to do one and not the other in either way.
dbaron: Either one would get us some good benefits
dbaron: But I think they are two independent things.
dbaron: When you start having multiple declaration of animations / ?
dbaron: One is about combining declarations, the other about
combining animations
dbaron: I think as far as the cascading pieces, bits about
combining declarations
dbaron: I think one of the reasons I prefer something simple here
is that I think something like !add or something like that
dbaron: It's simple enough, if we can agree on a syntax, it's
feasible to implement within existing engines in a
reasonable amount of time.
<astearns> I expect that if you're trying to allow more than one
framework to compose animations you're going to have a
lot of problems.
dbaron: I think fremy's other proposal has a lot more complexity,
and I'd be more hesitant to go down that path.
fremy: I'm not arguing for names, I'm arguing for numbers.
dbaron: There's a bit more complexity there, although a little...
I don't know.
dbaron: Other comment.
dbaron: Like fremy, I saw this as being only for list-valued
properties.
dbaron: I see that SMIL has more general mechanisms, and I have
mixed feelings for having those in the same system.
dbaron: It's pulling in a big part of SMIL to pull into CSS, to do
addition of other than comma-separated lists.
dbaron: Other small comment is that in that middle example, I
would expect animation-composite itself to be a
list-valued property
dbaron: And therefore I would expect that second line to be
animation-composite: add !add;
dbaron: Because I think you want to add your animation-composite
value to the list, not replace the list.
Myles: I have a couple points
Myles: One already made which is 2nd piece of proposal can be used
in many places
Myles: We've gotten lots of request for people to turn on various
font features
Myles: and this makes that easier.
fantasai: Use font-variant-* rather than font-feature-settings
fantasai: (This is why it exists and why using font-feature-settings
is strongly discouraged in the spec except where an
equivalent font-variant-* doesn't exist)
Myles: In WebKit we have an issue with text-decoration
Myles: If parent says text-decoration: underline and child says
text-decoration: strike-through
Myles: In both of those examples, the addition occurs down the
DOM, not across cascade.
dbaron: One of the cases we discussed is what happens if you have
adds all the way down.
dbaron: If you do adds all the way down on an inherited value
dbaron: you add to the base value, which for inherited properties
is the inherited property.
Myles: Other comment was on pulling apart a list and inserting
stuff in the middle
Myles: Issue of different teams trying to coordinate, this is
difficult for a company.
Myles: We already have two different ways for different areas of a
document interact.
Myles: The cascade through specificity, and then inheritance
through document tree
Myles: adding yet another way seems complicated, seems better to
re-use existing ones.
Myles: Another comment:
Myles: You had an issue of adding values...
Myles: If you have line-height: 50px and line-height: normal, how
do you add?
birtles: For some we use calc(), but some things can't add and
those fall back to replace.
birtles: In our impl, the function that does interpolation is the
same as the one that does addition.
fantasai: On that topic, if we have only the list-valued addition
for now
fantasai: That's avoids the problem of forwards-compat for types
that we can't add (or interpolate) yet.
fantasai: I think switching from replace to add is a more likely
compat problem than switching interpolation from
discrete to gradual in the future
Florian: so if you restricted to list-valued properties, then !add
would be a syntax error for other properties?
fantasai, dbaron: yes
birtles: I feel a bit uncomfortable drawing a line between list
types and non list types
birtles: in implementation terms there's no distinction.
birtles: For an author that you can add translate(200px) to
translate(200px) but can't add margins of 200px, seems
awkward.
birtles: Also ...
Florian: Less likely that people will use something that gets
thrown out and is a syntax error (though still possible
they leave it in the stylesheet, less likely)
Florian: than if it has a particular behavior (replace) and we
want to change it later to add.
Florian: Not an objection, but a concern about the compat path.
Florian: This allows things that were impractical
Florian: but also is same as using calc() in some cases.
Florian: I'm a bit worried about cases of e.g. Chrome shipping way
earlier than other impls and authors relying on it and it
being broken in other impls.
fantasai: This is an issue with every major feature we add to CSS,
can't decide to just not add things.
glazou: I'm a bit surprised we're using !add
glazou: Would prefer +property:value
dbaron: Would love property += value, but we're not using =
<astearns> property: value +add;
fremy: I'm OK to not have ability re-sort appending order
fremy: But I want ability to give added values different timing
rates
fremy: I want to say that "for this part I just added, I want to
transition the addition at a different rate"
Myles: For font-features that has no relevance, so this feature
should be scoped appropriately.
<fremy> btw glazou dbaron: my syntax proposal is { transform[]:
added-value; }
<TabAtkins> fremy: For poking at individual entries of a list, we
have the proposal for list-indexed sub-properties...
<fremy> astearns: yes; could be a different feature really, just
want to make sure we think about a path forward ;)
<TabAtkins> fremy: Just need to add commas to the transform
syntax, to let it become a comma-separated list.
<fremy> TabAtkins: yes, could work
Planning
--------
birtles: I would liked to get a go/no-go for shipping additive
animations
birtles: and also to gage interest with regards to refining the
static CSS proposal.
fantasai: I have no idea about Web Animations, but the additive
cascade is something people have wanted to have for a
long time, and it seems like your proposal has a lot of
interest from the people here.
fantasai: No idea how long it'll take but there's interest :)
birtles: We have same compat questions for the animated version of
the proposal, should they block us from shipping additive
animations or are they less severe in the case of Web
Animations?
fantasai: Was a suggestion to throw exception for things you can't
add.
fantasai: We can't do that in CSS syntax.
birtles: Probably worse for compat, since first browser to ship
will see unhandled exceptions.
fantasai: If we can throw exceptions for those cases and remove
later, less concerned about compat.
fantasai: If chrome ships auto+100px working, it's because they've
figured out how to make that work, and everyone else
will want to make that work.
dbaron: I guess I mostly disagree with fantasai's comment on
exceptions.
dbaron: I think the two things are mostly independent, and I don't
see a problem with animations stuff moving forward if
additive cascade doesn't.
birtles: What we have in the spec is a definition of addition for
each type, that needs to be written before shipping
birtles: pretty simple though.
birtles: Additive animations implementation
birtles: go forward, assuming test suite / compat etc.
RESOLVED: No concerns wrt shipping Web Animations
fantasai: Do we want to conclude something on additive cascade?
RESOLVED: CSSWG is interested in working on additive cascade
proposals.
fantasai: Can someone draft an ED?
astearns: I think it's premature to put in a spec.
* fantasai thinks drawing up EDs is a good way to work through
making a proposal more concrete, tbh
CSS Alignment
=============
Scribe: fremy
Baseline of a multicol box
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/1572
TabAtkins: Browsers disagree on what the baselines should be
TabAtkins: which is not very visible except in tables for instance.
TabAtkins: Firefox/edge/webkit consider the multicol has no
baseline, synthesize one.
TabAtkins: Chrome does use the first baseline of the first column
TabAtkins: but our last baseline is the last line of the last
column which is weird.
TabAtkins: The Chrome first baseline behavior could be useful
TabAtkins: Edge+Firefox could never be useful
TabAtkins: (the last baseline of Chrome is clearly wrong though)
<fantasai> testcase: http://output.jsbin.com/cenefep
TabAtkins: Our proposal is to have the spec match Chrome for first
baseline.
TabAtkins: For last baseline, we are ok with synthesizing at the
bottom.
TabAtkins: We could try to find the bottomest baseline of all
columns but that is complex and probably not very
useful anyway.
TabAtkins: See linked test case, it really looks bad.
Rossen: Why is that useful?
[fantasai draws a picture where the title is in the left margin of
the page, and is baseline-aligned to the first line of its
content, which is a multicol element just to the right of it,
layout similar to
<td>TITLE</td><td>[ multi col ]</td>
]
<astearns> I agree with the first baseline idea, but I don't like
the idea of using something that isn't a baseline for
last baseline
<astearns> I'd rather take the baseline of the last line in the
first column
dbaron: I would be very nervous about anything that tries to use
highest thing or lowest thing in columns because baselines
could affect size which could affect distribution of lines
of the columns.
<Myles> dbaron: can you give an example where baseline alignment
affects size? Vertical centering?
<dbaron> Myles, vertical-align:baseline in a table row with fixed
height
<Myles> dbaron: 👌
<dbaron> and I think css-align introduces more
TabAtkins: That rules out using last baseline of the first column
then.
Florian: If it's hard and useful, we should still try to do it.
TabAtkins: I don't think it usually very useful
TabAtkins: and synthesizing is close enough.
fantasai: That is not accurate though.
TabAtkins: Very rarely needed.
dauwhe: Baseline alignment between columns is useful though.
TabAtkins: This is something completely different-
TabAtkins: still useful but very different.
[dauwhe gives example of footnotes in last column, last line of
footnotes is baseline-aligned to last line of previous column]
Myles: line-grid usecase, basically.
Rossen: Proposed resolution: first baseline = first line of first
column; for last baseline, synthesize based on bottom
margin edge.
Rossen: We think it is easy to implement.
Rossen: For last baseline it looks mostly ok to me.
Rossen: I have seen zero bugs about this.
<fantasai> I think we need s/margin/box/
<fantasai> because margin vs border varies atm
<fantasai> depending on context
astearns: They have not even had a chance to try.
Rossen: We have had multicol + grid for 5+ years.
Rossen: Nobody every asked me this anyway.
Florian: I might have wanted this but I can live without.
Rossen: So, can resolve on proposal?
Rossen: Any objections?
RESOLVED: First baseline of multicol is first baseline of first
col, last baseline synthesized as described above.
Syntax for fallback alignment in the place-* shorthands
-------------------------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1002
TabAtkins: We would like to allow all combinations in the
shorthand that are possible in the longhands
TabAtkins: but if we just allow spaces, this would be ambiguous.
TabAtkins: We need to have a separator to know which values are
fallback for what.
TabAtkins: Usually this kind of separator is the slash "/"
TabAtkins: but if we decide to use a separator, should we do
axis-1 / axis-2 or value/fallback value/fallback.
TabAtkins: Former is annoying because you always need the slash
TabAtkins: I believe the latter is better for that reason.
fantasai: It would make the longhand easier to read
fantasai: (the slash)
TabAtkins: There would be a proposal to make the longhand also
have the slash.
fantasai: The proposal is to do both, not just for shorthand.
TabAtkins: Even align-content would use space-between / center
TabAtkins: with center as the fallback.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1002#issuecomment-311501471
<fantasai> align-content: space-between / center
<fantasai> place-content: space-between / center
<fantasai> place-content: space-evenly / start center
<fantasai> -> align-content: space-evenly / start;
justify-content: space-evenly / center
<TabAtkins> place-content: space-evenly space-between / center; <=
different distribution, same fallback
Rossen: I like it better than what we have right now.
rachelandrew: I think it makes sense.
Rossen: Anyone else?
Rossen: Let's resolve then.
Rossen: Any objection to use the slash for fallbacks in all
alignments?
RESOLVED: Slash must be used to separate main value and fallback
value in shorthand and longhands alignment properties.
<br type=lunch>
Received on Sunday, 27 August 2017 18:57:16 UTC