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

[CSSWG] Minutes Paris F2F 2017-08-02 Part II: Media Queries 4, Additive CSS, CSS Alignment [mediaqueries] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 27 Aug 2017 14:56:20 -0400
Message-ID: <CADhPm3tLi5S_v537nSZgTFjp2bN0eqkjhQ5ef9K-r0-LmbhyqQ@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.

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:
      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
  - RESOLVED: No concerns wrt shipping Web Animations
  - RESOLVED: CSSWG is interested in working on additive cascade

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)


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
  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
  tantek: it mentions stability, and royalty-free-ness of the spec.
  tantek: Whether or not the spec is freely available is mentioned
  glazou: The ISO specs are also in this area. Not available for
  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
  tantek: Another approach would be to provide a small subset
  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
  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

  RESOLVED: Florian to move the reference to informative, and
            provide specification text describing the color space
            (color values, white points, etc)


  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?

  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
  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
  birtles: wherever in the chain doesn't say add, clobbers earlier
  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
  birtles: then need to define order, since not operations are
  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
  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
  <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
  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

  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
  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

  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
  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

  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'
  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
  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
  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
  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


  birtles: I would liked to get a go/no-go for shipping additive
  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
  fantasai: Was a suggestion to throw exception for things you can't
  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

  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

  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
  TabAtkins: For last baseline, we are ok with synthesizing at the
  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
  <Myles> dbaron: 👌
  <dbaron> and I think css-align introduces more
  TabAtkins: That rules out using last baseline of the first column

  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

  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

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