W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Telecon 2016-11-23 [css-grid] [motion] [css-masking-1] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Nov 2016 21:45:27 -0500
Message-ID: <CADhPm3vFFBuf8CYynDE=JbyGCcUPGJ-Zhbroa2BKcneQcwkVNw@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.

TTML2 horizontal review request

  - Anyone with interest was asked to respond to the review request.

Remaining Grid Layout Issues

  - fantasai wasn't ready to discuss these issues yet so the
      conversation will continue in hopes of being able to come to
      the group for resolution next week.

offset-rotation vs rotate

  - RESOLVED: Rename offset-rotation to be offset-rotate
  - TabAktins was actioned to confirm this change is okay with Blink
      since no one was on the call to speak for them.

Was the position of 'mask-mode' in the 'mask' shorthand intentional?

  - RESOLVED: mask-mode can be anywhere in the mask-shorthand other
              than between position and size

Add shorthands for alignment properties

  - There were concerns that adding the slash created an
      inconsistency with other established properties such as in
  - On the other hand, there was a feeling that the slash would be
      intuitive to those that use grid and flexbox and that not
      having the slash creates a bad precedent.
  - RESOLVED: Don't add the slashes.

  - The group moved on to discussing what would be needed to move
      Align to CR since there are dependencies for Grid.
  - fantasai proposed trimming the spec to have only single-keyword
      values only for longhands in this level of Align and moving
      the rest to the next level. These properties are derived from
      Flexbox and are therefore stable and unlikely to change.
  - dbaron expressed a desire to know what is already shipping in
      browsers before removing items from the spec so discussion
      will continue next week once there's a fuller picture of
      what's shipping.

====== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0101.html

  Rossen Atanassov
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Peter Linss
  Michael Miller
  Anton Prowse
  Liam Quin
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Steve Zilles

  Rachel Andrew
  Vlad Levantovsky
  Myles Maxfield
  Greg Whitworth

Scribe: dael

  Rossen: Any extra items?
  tantek: Not an extra, but a request to talk about #8 on the agenda
  Rossen: And what's the reason?
  tantek: We've been trying to do it for ages. We need a resolution
          because we're trying to ship soon. Like today.
  Rossen: How about I make sure we have time? We have other issues
          that were issue+ a few weeks ago on fx list that we missed.
  Rossen: Any additional requests?

TTML2 Horizontal Review Request

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Nov/0091.html
  Rossen: Anyone with interest or spare time could do this review
  Rossen: I added the item to bring attention.
  Rossen: Please take notice if you're interested. The deadline is
  Rossen: They don't have an exact one but let's assume they're not
          far off.

Remaining Grid Layout Issues

  Rossen: There were a bunch of issues from an implementor.
  fantasai: What I meant in my e-mail is all the keywords and values
            in flexbox or anything trivially analogous. Any single
            value syntax of alignment is stable enough to ship. Any
            two value I'm less sure about.
  Rossen: What about min/max?
  fantasai: The implied size of grid items I haven't looked in
            detail yet.
  Rossen: Okay, so we're not ready yet. We should look as this could
          be behavior change in the spec.
  Rossen: You mentioned item 3 on the list from the dev you've
          looked at?
  fantasai: I haven't had time to do anything. I'll work on things
            starting today.
  Rossen: So it should like we can't make much progress today.
  Rossen: I'm not hearing any takers. Let's push to next week.
  fantasai: I'm hoping we can close next week.
  jensimmons: I know FF engineers are looking to ship so there's
  Rossen: Yep. That's the same vibe I'm getting from Chromium impl.
  <gsnedders> (It's no longer behind the experimental flag in
              Chromium now)
  Rossen: We've got the attention of the right people.

offset-rotation vs rotate

  <Rossen> https://github.com/w3c/fxtf-drafts/issues/70
  jihye: In motion path there is a property name offset-rotation and
         it defines the object's orientation that's positioned along
         a path.
  jihye: fantasai pointed out there's a rotate property in transform
         spec and using the work rotate would be grammatically
  jihye: I agree because features in CSS are using rotate. Therefore
         I think renaming to offset-rotate is reasonable.
  jihye: I worry that the property is already shipped in Blink. Will
         renaming matter for the implementation?
  <jihye> https://drafts.fxtf.org/motion-1/#offset-rotation-property
  <jihye> https://bugs.chromium.org/p/chromium/issues/detail?id=637543
  Rossen: Anyone from Blink on?

  <dbaron> One other concern is that I feel like property names are
           usually nouns or adjectives rather than verbs

  fantasai: I suggest we resolve that if shane says it's okay we
  Rossen: That would mean for them they would need an alias for some
          time. I'm okay with going with that. I wanted to hear if
          anyone else in the WG has an opinion on renaming
          offset-rotation to offset-rotate.
  dbaron: We usually use nouns or adjectives not verbs. We've mostly
          been consistent about that. So I feel like it's the names
          in transforms that are unusual though consistent with
          values for transform
  fantasai: I think that's more important. We try and reduce amount
            of grammatical morphemes. We try and avoid conjugations.
  dbaron: Like text-decorate?
  fantasai: That's an exception
  dbaron: I think there's others.
  fantasai: Yeah.
  <dbaron> font-vary, direct, color-interpolate, opaque :-)
  <Bert> (but vertical-align and text-align rather than
  <jensimmons> background-position
  <jensimmons> text-transform
  <jensimmons> position
  <jensimmons> text-decoration:

  fremy: Since there's no one from Blink I can't speak for them but
         maybe we should not change it because the value of changing
         isn't that big and we'd break an implementation.
  Rossen: fantasai proposed renaming it but leaving it open until
          someone from the Blink team looks at it.
  fremy: That's fine too.

  Rossen: dbaron's point about already having some inconsistency is
          a valid point. Do we want to have offset-rotation to be
  Rossen: fantasai do you feel strongly?
  fantasai: We should resolve the inconsistency. We're using rotate
            in the transform name and the value of the property. So
            offset-rotate must be consistent. We can consider making
            the value use rotation but I'm not sure that's good. For
            people that don't speak English it is more confusing.
            The noun vs verb thing is nice, but consistency within
            CSS is much more important principle.
  dbaron: I'm okay with that.
  <tantek> +1 to what fantasai said about preference of consistency
           over grammar

  fremy: Having a quick look, there's flex-direction,
         text-decoration, font-variant-position...we have a lot
         ending in -tion
  Rossen: I think it's about consistency.
  fremy: We have a lot that add in -tion
  fantasai: We have rotate already. It's more important to be
            consistent with those long existing properties then be
            consistent with something with the same grammatical
  fremy: Uh, if you say so.
  <glazou> +1 with fantasai
  Rossen: I'm also with you. I'd take consistency over repairing
          past mistakes. Let's put this to a decision.
  Rossen: Obj to rename offset-rotation to be offset-rotate?
  <glazou> +1
  <Bert> +1 to fantasai (offset-rotate)
  <astearns> +1 with fantasai
  <tantek> +1

  RESOLVED: Rename offset-rotation to be offset-rotate

  ACTION TabAtkins make sure that rename offset-rotation to be
         offset-rotate isn't a problem for the Blink team
  <trackbot> Created ACTION-803

Was the position of 'mask-mode' in the 'mask' shorthand intentional?

  dbaron: Basically the mask shorthand is defined so that mask-mode
          has to be positioned right after mask-reference
  dbaron: I feel like that was a typo rather than intentional where
          we want the shorthand to mostly allow arbitrary
          re-ordering except this thing. I believe Gecko impl as
          though there's a || but no one can answer if this is
  Rossen: What is your proposed change?
  dbaron: Add an or so that mask-mode can be anywhere in the
          mask-shorthand other than between position and size.
  Rossen: Do we have a Blink implementation on that one?
  dbaron: I don't know.
  dbaron: I think there's implementation of the mask shorthand, but
          I don't know if there's mask-mode in it since it's newer.
  Rossen: What about webkit?
  Rossen: I don't hear anyone. Any other opinions on this?
  Rossen: Objections?

  RESOLVED: mask-mode can be anywhere in the mask-shorthand other
            than between position and size

Add shorthands for alignment properties

  <astearns> I vote for the value syntax using /
  fantasai: I think the main issue is we resolved on place-* but
            what do we do about two value keywords?
  <fantasai> align-content: space-around start;
  fantasai: I can write ^
  fantasai: If you have place-content and have a space separator you
            can't do that because it would be...
  <fantasai> place-content: space-around start; align-content:
             space-around; justify-content: start;
  fantasai: Suggestion is to use / separator. Problem with that is
            we're using the same syntax to represent alignment in
            other places, such as scroll snap and
            background-position and they don't use slashes.
  fantasai: We could go back and change the other specs since
            scroll-snap is newer and background doesn't have the
            logical keywords so we could require it for the logical
            keywords but that doesn't make sense because
            background-position is part of the background short hand
            that uses slashes. So in background-position we can't
            use the / to separate the keywords.
  fantasai: We have two options. 1) we use a / in the place
            shorthand but not anywhere else which gives us an
            inconsistency or 2) we say the shorthand can only take
            one keywords values so if you want two values you have
            to use the long hands and the short hand is space
  fantasai: Is that clear?
  fremy: Clear to me.

  fantasai: So that's the decision. I'm inclined to go with space
            separation for consistency with the other properties.
  <tantek> I'm ok with 2
  <tantek> to keep it simpler / more consistent with existing
           properties for now
  <tantek> and be ok with the restriction
  fremy: Seems reasonable. So you can't do two keywords in the
  fantasai: Only to do alignment value of single axis.
  fremy: Can we make a function that would take two keywords?
  fantasai: That's a possibility.
  fremy: I think then you don't lose any expression and you don't
         have to remember a space.
  fremy: In the meantime I agree with you the best option is we use
         space like everything else and we can consider this in the
  astearns: I think the future extension would have to be a
            function. This is not simpler, you have to remember you
            can only use single value keywords in the shorthand.
            People will be confused when they try and use a keyword
            that works in the longhand. Adding a function doesn't
            solve that confusion, you have to remember something
  fantasai: You'd use the same syntax in shorthand and longhand. The
            second value is a fallback. Space between if you have
            multiple items you put space between, but what happens
            if there's only one item? It's a fallback. We could
            consider a different syntax. We're doing space and then
            the other value. We could introduce lots of keywords or
            introduce a function or something else.
  astearns: I'm a little concerned about the precedent. The
            precedent if we take is for any long hand that takes
            values that's anything like background-position you
            can't use a slash. We're limiting more things because we
            didn't consider an ambiguous syntax with these. When we
            have ambiguous syntax we add slashes. I think that's the
            better precedent to follow.
  <jensimmons> +1 to astearns
  fremy: I won't disagree. In this case it seems like mostly it's a
         fallback and in fallbacks we use a function.
  astearns: Here it's using a function to get around the ambiguity
            of the two value version.
  astearns: I don't see the function being a simple fix. It add
  astearns: I'd rather in the cases we know there can be positional
            ambiguity we use a slash. It preserves expressivity of a
  fantasai: I think there will be cases where we expect no ambiguity
            and we'll have it later. In this case we can predict it
            because we thought of the feature early. THere will be a
            lot of cases where we won't come up with it early on.
  <tantek> can't we add the slash option later if actual author need
           is demonstrated?
  fantasai: We can add a slash later where two values is space and
            four is slash (to tantek)
  <tantek> I'm thinking this is a non-issue for authors
  <tantek> (the additional functionality that would require slash)
  <tantek> that is, not worth introducing new syntax for
  <tantek> I'd rather defer adding slash option until a need is
           demonstrated later
  <tantek> since we *can* add it later
  jensimmons: I think the slash will feel natural to people learning
              grid and flexbox. I think most people don't know you
              can have two values. I think it could be useful. Just
              to toss it in from an author's perspective.

  Rossen: I'm hearing some people, maybe most, in favor of slashes.
  Rossen: I think fremy was arguing the other way. Do you feel
  fremy: I don't feel strongly. For me it's strange to add the slash
         because when you use them in the short hand they'll be out
         of place. It'll be weird but I don't care that much.
  fantasai: One possible thing we can do in the future...we could
            consider to add more of a gradient between so we
            represent start as 0% and center as 50% so we can merge
            background-position and alignment in that fashion. I
            think that's a real possibility in the future and then
            the discrepancy would be more confusing as they'll
            overlap more.
  fantasai: Something else to consider.

  Rossen: Let's try for a resolution.
  Rossen: Objections to adding the slash?
  fantasai: I wouldn't object, but I have strong reservations
            because of the things I've explained.
  tantek: Would anyone object to deferring adding a slash?
  tantek: We could ship without that. We don't need that
          functionality. Authors don't care right now. We're adding
          syntax for an edge case.
  fantasai: I think it'll turn up but we don't need it right now.
  jensimmons: I think limit this so you can't put two values in, I'd
              be on board for that. If people learn about it let's
              create a fallback of the longhands. I don't think it's
              realistic to say we ship it one way and change. If we
              don't ship the slash now let's resolve not to do it.
  fantasai: Agreed on that point.
  Rossen: So we can take out the slash?
  Rossen: So then, tantek wants to resolve so we can ship.

  jensimmons: The other debate was the order of things. Many people
              in the WG who understand grid say align then justify.
              A lot of authors say it feels more natural to be
  fantasai: We had this debate TPAC a year ago. We have...I'll have
            to look at the minutes but there's a set of problems
            where if we do logical does block or inline come first
            and we resolved on inline first. scroll snap and
            background-position 4 does it that way. So place would
            be consistent. We decided 2 value and 4 value should be
            block and then inline so there's consistency.
  fantasai: Physical values we have now does x and then y, but
            margins and borders do y then x.
  fantasai: We would have to have an inconsistency somewhere so we
            resolved to say if you're using logical then the
            coordinates will always be block and then inline so all
            of grid is that way.
  fantasai: If you look at grid placement property vs grid template
            property. If you look at grid template the old system
            would be x then y, but grid placement because they're 4
            valued they would be y then x.
  fantasai: So we wanted to make those consistent so 2 value vs 4
            value has to be consistent and if we're doing it in grid
            it should be in the other logical values. That let's
            have margin and border be consistent.
  jensimmons: Okay. Thanks for the background.
  fantasai: Ideally we'd go back in time but we can't.

  Rossen: We want to take a resolution here. Let's try and take one
          to not add slashes. Objections?
  <tantek> +1

  RESOLVED: Don't add the slashes.

  Rossen: Is there a second one?
  <SteveZ> I thought that the resolution was that two values were
           not allowed
  <Rossen> SteveZ: this is the next one
  fantasai: Ordering was resolved a year ago. I believe that's on

  <jensimmons> SO: this place-items: <'align-items'>
               <'justify-items'> ;
  <jensimmons> place-self: <'align-self'> <'justify-self'> ;
  <jensimmons> place-content: <'align-content'> <'justify-content'>;
  <jensimmons> or here (where it’s easier to read):

  fantasai: I think it would be wise given we want to ship to take a
            cut of the alignment spec and just spec to have only
            single value for each of the properties other then the
            shorthand. So dropping fallback and safe/unsafe
            alignment to give us more time.
  fantasai: I'm not sure how impl feel but that would reduce the set
            of new things.
  <tantek> +1 to what fantasai said
  <tantek> this seems conservatively prudent
  fantasai: There has been some cross-consistency concerns and I
            want to defer that entire set of topics by pushing to a
            next level.
  dbaron: Aren't some of those things shipping?
  fantasai: I don't know.
  dbaron: I think we're shipping safe|unsafe. I don't know on
  fantasai: That's a space around left, I think. Two values on
            distribution. I think we recently resolved on
            first-baseline and last-baseline. I'm just concerned
            we'll want to change these or at least syntax.
  tantek: They haven't been sufficiently incubated.
  Rossen: So let's try and move forward instead of talk about

  fantasai: If implementors want to keep them in but I want to drop
            as much as I can.
  Rossen: It sounds like tantek wants to ship and he's also
          supporting moving them out. We can resolve and you can
          take an action to do it.
  tantek: I can live either way. We are shipping it. I can't speak
          to the certainty.
  fantasai: We just discussed recently changing fallback.
  Rossen: Sounds like the rest is stable.

  tantek: Who else is shipping?
  Rossen: We're not.
  jensimmons: Sounds like there's no one from Chrome/Webkit here.
  tantek: Does Edge like the design? DO you plan to ship?
  Rossen: I can't comment.
  tantek: That's fine.
  <dbaron> I think we're shipping the whole ' <content-distribution>
           || [ <overflow-position>? && <content-position>' bit of
           align-content and justify-content

  Rossen: Let's get back to the proposal. And SteveZ pointed out we
          were trying to resolve on if we allow two values for that
  Rossen: Sounds like if we move this the resolution can happen
          later on.
  <dbaron> We also wouldn't need to have this discussion if we
           resolve to use / in the place-* shorthands...
  Rossen: Do we have objections to moving this to the next level?
  jensimmons: I'm a bit confused what we're talking about, but issue
              595 on github we have consensus on everything on this
  fantasai: We resolved on that.
  fantasai: This is the align-content property there's two values.
            I'm suggesting we reduce the long hand options to just
            the single values. Just so we can have this. We may sort
            this out, but to reduce the amount of stuff looking for
            cases to switch the syntax or other concerns,
            particularly with expressing them in shorthand.
  fantasai: We're clear on baseline where first/last keyword has to
            go first. Beyond that we need to check the syntaxes work
            the way we want them to and work with the shorthand.
  fantasai: That's my concern. I'm happy to defer. The stable things
            I feel are single values on longhands.

  dbaron: I feel like we're opening up a lot of issues because the
          resolution we just took. If we reconsider the slash then
          we don't have to open all these other things.
  Rossen: That's reasonable as well.
  Rossen: I want to close on this today and get to CSS 2.2. If we
          don't resolve on moving this forward, fantasai what do you
          feel will hold up the spec?
  fantasai: In terms...assuming we go with these resolutions what
            will hold the spec is I have to go through a bunch of
            edits and we can publish next week. There's a handful of
            stuff I think should drop. The legacy value in
            justify-items that needs more work. The stuff I know is
            stable is the single keyword values that are directly
            analogous to flexbox. If we cut out the rest it will be
  fantasai: There's problems with things that derive from combining
            keywords. Syntactic and also this thing is not well
  fantasai: I don't think it'll take long to figure this out, but I
            want to ship tomorrow I would recommend do the single
  Rossen: You'd recommend for not a single value?
  fantasai: I would recommend to drop any features in css align that
            require > 1 keyword in the longhand.
  Rossen: Thanks.
  fantasai: There's several features in that. safe|unsafe is
            probably okay.
  Rossen: If we set the spec it gives us more reasons to stall. I'd
          rather not defer work to just defer work if we can in a
          reasonable time frame think through those issues.
  fantasai: Because there's a grid dependency I think the smartest
            thing to do is...we've shipped a bunch of stuff in
            flexbox and there's a lot that's directly analogous. We
            can't change the syntax there the definitions are
            straight forward. There's nothing to change. Those are
            stable. As a let's ship now for grid that's a good
            subset to pick. If we want something out tomorrow let's
            cut down to that set.
  fantasai: We know it works and we have impl experience with that

  Rossen: Let's put it to the group. Objections on resolving to move
          all the features to level 4 in favor of shipping a stable
          subset that's interoperable with flex and will allow grid
          to be fairly interoperable?
  dbaron: I'd like to have a better understanding of what's shipping
  fantasai: All the positional values, baseline and last baseline
            with the resolution that changed them.
  <fantasai> https://drafts.csswg.org/css-align/#positional-values
  <fantasai> https://drafts.csswg.org/css-align/#baseline-values
             section with last- replaced with [first|last]? per
             previous resolution
  <fantasai> https://drafts.csswg.org/css-align/#distribution-values
  astearns: I think dbaron wants to know what's in the browsers.
  fantasai: Oh. I don't know.
  dbaron: I think we should know what's shipping, not just guess.
  fantasai: We can discuss next week. I don't know.
  Rossen: I don't know either.
  jensimmons: That sounds right. To go find out and come back next
              week and make a resolution.
  Rossen: We're at the top of the hour anyway.
  Rossen: We've been going back and forth for 14 minutes which
          indicates we're not ready.

  Rossen: I want to give the last minute to fantasai to list what's
          remaining in level 3.
  Rossen: You mentioned position and baseline?
  fantasai: All properties would stay. position, alignment keyword,
            baseline keywords with first/last prefix and distributed
            alignment keywords. But no combination of those in
            level 3.
  <fantasai> Single-keyword values only, for longhands.
  Rossen: We have this in the minutes. If we read this before next
          week we can resolve on keep or move.
  fantasai: And I'm happy to pull things in and ship level 4 in
            February. In terms of what's set to go today it's the
            single keyword stuff.

  Rossen: Thanks everyone. Have a good rest of the day and talk to
          you next week.
Received on Thursday, 24 November 2016 02:46:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 November 2016 02:46:31 UTC