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

[CSSWG] Minutes Telecon 2017-06-28 [css-writing-modes] [css-variables] [css-counter-styles] [css-logical-props] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 28 Jun 2017 20:25:33 -0400
Message-ID: <CADhPm3syzXQ9td_5UFVaj9NEbza5kxb6Sb+0Qap0_+hQOOKxsQ@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.

Spec Rec next steps

  - Rossen will confirm if Writing Modes needs a CR publication
      before the PR request.
  - Variables needs to republished after the tests are approved.

Propose to make "disc" not overridable

  - RESOLVED: make "disc" not overridable.

Naming of inset-* properties prefix

  - RESOLVED: adopt inset as the new positioning property name
              that's used for shorthand.
  - fremy will create a poll with a description and diagrams to
      evaluate if this name is preferable over some of the other top

Should 'place-items' accept 'legacy' values?

  - RESOLVED: leave behavior as-is and not accept 'legacy' values
              for 'place-items'.

Are there compatibility issues with replacing overconstraint rules
    from CSS2

  - RESOLVED: Accept the proposal that margin and position
              properties will return the specified values.

Don't introduce baseline alignment to table columns

  - RESOLVED: The baseline alignment in block direction of tables is
              not defined. Also add a note prompting implementors to
              bring back ideas if they have any.

Should 'left' and 'right' really both fall back to 'start?

  - RESOLVED: Leave the left and right values to fallback to start.
  - RESOLVED: Remove 'left' and 'right' from align-self and
              align-content in align L3.

Reconsider name of frames() timing function

  - birtles gave a brief introduction to the topic in hopes of
      getting more discussion in the github issue
      (https://github.com/w3c/csswg-drafts/issues/1301) before next
      week's call.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0034.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Brian Birtles
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Rachel Nabors
  François Remy
  Melanie Richards
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Bert Bos
  Emil Eklund
  Simon Fraser
  Vlad Levantovsky
  Anton Prowse
  Florian Rivoal
  Jen Simmons

Scribe: dael

Spec Rec next steps

  Rossen: Hello everyone! Any extra agenda items?

  Rossen: There were a few actions since last time. I was curious if
          they materialized.
  Rossen: fantasai, I was wondering if we made progress on Writing
          Modes, Values & Units or UI.
  fantasai: Values & Units has a DoC and I need to next fix the
            changes list.
  fantasai: Writing modes nothing this week.
  Rossen: I see last week we had a question on CR or PR. I looked at
          minutes and I believe we agreed PR.
  fantasai: It was if process requires CR first because there were
            substantive changes.
  Rossen: Okay. I'll reconfirm with Chris or Bert. I recall it was
  * fantasai wonders if tantek knows the answer to that question?
  <tantek> fantasai just missed it
  <fantasai> see above
  <fantasai> writing modes to PR
  <tantek> IIRC you can go direclty to PR (and request PR
           transition) IF you have satisfied all the CR exit
           criteria. I believe you still have to have the minimum CR
           period during PR
  <tantek> hopes that helps
  <tantek> In fact I say go ahead and do that (if those conditions
           are satisfied), and if you get push back from anyone, I
           want to hear about it
  <fantasai> tantek, ok, thanks!
  <tantek> I prefer to push the limits of being efficient with the
           Process, and find out where it breaks or blocks
  <tantek> and then I can escalate to the AB
  <tantek> (or anyone can escalate to the Process IG)
  <tantek> (or both)

  Rossen: And V&U was waiting on DoC.
  Rossen: And the reviews to UI tests haven't been done, right?
  Rossen: I'll take that as a yes

  Rossen: gregwhitworth, Variables. Did we get progress on the tests
          you needed reviewed?
  gregwhitworth: Yeah, they're checked in.
  Rossen: Is the next step republish?
  gregwhitworth: I'm assuming that's a q for the editors.
  Rossen: I think it's only TabAtkins.
  TabAtkins: I'm happy to republish.
  Rossen: I wonder...how many tests to we have for the ones you
          submitted gregwhitworth.
  gregwhitworth: I have to pull it up.
  Rossen: Okay, we can move on. But it would be good to know so we
          can move toward PR.

  Rossen: Last was flexbox. Did you hear anything back from anyone
          in regards to test coverage?
  gregwhitworth: I sent last night the pulls outstanding. There's
                 one more outstanding. I haven't heard back and
                 since I didn't now how the process went I sent my
                 summary as to what I saw. Implementations are
                 interop in my opinion.
  gregwhitworth: There will be 3 PRs and hopefully the editors can
                 look and pull those in. Christian B has been
                 waiting a month on intrinsic sizing.
  Rossen: So TabAtkins myself and fantasai is who that's on. It
          feels this spec should be close to done.
  gregwhitworth: I have one more PR to do this week but once they're
                 accepted we're done.

  Rossen: I'll resend the doc on spec updates and to dos. A few are
          behind, but a lot are waiting on tests to be provided.
  <fantasai> was that for flexbox? There are still bugs in flexbox
  <gsnedders> yes
  <fantasai> There's a lot of non-interop on auto-sized images in
  Rossen: We'll move on for now, please reply to the next email.

Propose to make "disc" not overridable
  Github: https://github.com/w3c/csswg-drafts/issues/1521

  TabAtkins: It would be easier if disc was not overwritable so they
             didn't have to load the counter styles. I don't see
             anything wrong with this. I only have one
             non-overwritable which is decimal. I need WG approval.
  fantasai: Are we switching non overwritable from decimal to disc
            or making both non-overwritable?
  TabAtkins: Both

  Rossen: Proposal is make both non overwritable?
  TabAtkins: Make disc non-overwritable.
  Rossen: Any other opinions?
  fantasai: Now that disc is non-overwrite do we need decimal too?
  TabAtkins: We do. Decimal being the ultimate fallback it's better
             to see what you started with when you screw everything
  Rossen: fantasai is that good?
  fantasai: I don't have an objection, I just wanted there to be a
  Rossen: Objections to make "disc" not overridable?

  RESOLVED: make "disc" not overridable

  Rossen: TabAtkins please make the change

Naming of inset-* properties prefix
  Github: https://github.com/w3c/csswg-drafts/issues/1519

  fantasai: We needed to rename the logical equivalent of the
            top/left/bottom/right properties and the shorthand for
            them. We wanted that to be the prefix for the logical
            properties. We were using offset as the word here.
  fantasai: That conflicts with motion so proposal was rename the
            offset properties. Top option is inset, but there's
            other suggestions in the issue.
  Rossen: I was just looking at the list and ~20 days ago was when
          Sebastian posted results and then position-offset had the
          most votes. You said that would collide with motion path?
  fantasai: Offset would. Position-offset wouldn't, but
            position-offset isn't a shorthand. It would be
  fantasai: I think it's in author interest to stick to a shorter
  Rossen: inset is not supposed to be position-inset
  fantasai: Yeah. inset: [value for top/left/bottom/right]. You'd
            also have inset:inline-block. It would be like the
            margin [missed] We also have inset:block
  <astearns> might be better to type the syntax

  Rossen: Any opinions?
  <AmeliaBR> inset isn't great for relative position
  <astearns> I like inset
  fremy: I think inset is strange. For position relative there's
         nothing to do with inset.
  bradk: I like it because positive numbers go inwards from
         reference box
  Rossen: Not when you factor in logical
  TabAtkins: Yes still. They always go inward.
  fremy: It's not inset to anything for position: relative
  fantasai: It's inset from its original position. Agree it is a
            nice term because it reflects we're going inwards in a
            positive direction.
  fremy: I'm not convinced. If you look at the proposal list inset
         isn't in it. I don't think it's clear to authors. I'm
         surprised we asked for opinions on twitter and picking
         something not offered.
  fantasai: If we want to do this on twitter we need to put the
            whole list and randomize. A lot of people took what came
            to their head and posted it. If you want data we can do
  fremy: None of the proposals are inset. It wasn't included as an
         option to think of. To me it's not intuitive. I wouldn't
         think it has anything to do with top left bottom right. I
         won't object, but we did a pole and no one came up with
  fantasai: It is in the list. Several people in the WG
            independently came up with that term: at the F2F
            astearns did, bradk on a list, and me another time. In
            twitter we can't give all the information for the
            decision and people use this in a way that doesn't
            reflect how it's going to be used in all the alignment
  fantasai: People think about it how they position the top left
            corner and that's not really the case, especially in
            other writing modes. There's a lot going on that's not
            just how I position this absolutely. There's a lot of
            suggestions that are based on 2 axis abspos. We have to
            consider all the layout modes.
  fantasai: Blindly taking info from twitter isn't the right way. If
            you want data we can post a poll so people can read and
            understand what's going on.

  fremy: My concern is that inset suggests that you can inset from a
         place. If you're position relative I'm pretty sure you
         can't take the four of them. If position relative doesn't
         have a starting box I don't know how you use inset.
  fremy: I don't understand how position relative is inset from
          anything. The name doesn't seem intuitive to me.
  bradk: For position relative you can set just right and bottom and
         positive numbers are inwards from the bottom and right edge
  Rossen: They're offset of the initial position.
  bradk: Your bottom will move inwards from where the bottom was.
  fremy: It's only changing position not size and inset suggests you
         could do size.
  TabAtkins: What are y'all talking about? Abspos is inward from the
             containing block, relpos is inward from the element's
             own bounds.
  TabAtkins: It's not a point.
  <AmeliaBR> The idea is that in position:relative, it would "Inset"
             relative to the normal position of the box. But you
             can't inset on opposite sides, because you're not
             changing size of the box.
  <AmeliaBR> ...but, that's confusing. "offset" was better for that
             purpose, but that's unavailable now.
  * TabAtkins suspects that either some people have forgotten how
              relpos works, or are interpreting it in a way that's
              functionally identical to what we're saying, but
              phrasing it in a totally different way.

  Rossen: There's a couple ways forward. If a WG member that is an
          avid CSS user is confused chances are he's not alone. We
          can adopt the inset as the current name and continue the
          discussion. If there's enough people who would like more
          votes on a short list we can limit the choices to the top
          10 votes, include inset, randomize order, and in that way
          we'll see if inset makes it.
  Rossen: Given those choices, preference?
  fremy: I'm fine inset for now and then make a poll.
  Rossen: You wouldn't object to accept inset and continue the
  fremy: No.
  Rossen: Any others that would object to adopting inset as the new
          positioning property name that's used for shorthand?

  RESOLVED: adopt inset as the new positioning property name that's
            used for shorthand

  ACTION fremy to create a poll to get more data on the inset name

  fantasai: If we're positing a poll can it have all the relevant
            background and diagrams.
  fremy: Yes. I won't do this on my own.

Should 'place-items' accept 'legacy' values?
  Github: https://github.com/w3c/csswg-drafts/issues/1449

  fantasai: I don't have an opinion, it's question of so we have the
            shorthand for various legacy items of justify:items. It
            takes 'legacy' as a keyword alone or in combo of other
            values. Do we want it in the shorthand.
  TabAtkins: I'm on the side of no. There's no real reason for
             authors to specify that for themselves.
  Rossen: The legacy one should be left for legacy.
  dbaron: One of the tradeoffs is that it becomes harder to
          serialize to the shorthand. You end up with cases where
          you can't serialize the shorthand.
  TabAtkins: I'm not sure. But only if you have the place-items
             shorthand on a center element, I think. So...ehh.
  <fantasai> Don't we already have other cases where there are
             values that aren't possible to express in the shorthand?

  Rossen: dbaron would you object if we didn't?
  dbaron: I'm okay, I just wanted to bring that up
  Rossen: I heard fantasai and dbaron being okay with...fantasai was
          fine with either, dbaron would be okay if we stayed with
          current version. 2 others voted stay with current. Other
  <fantasai> what's current?
  Rossen: Objections to leaving behavior as-is and not accept legacy
          values for place-items.

  RESOLVED: leave behavior as-is and not accept 'legacy' values for

Are there compatibility issues with replacing overconstraint rules
    from CSS2
  Github: https://github.com/w3c/csswg-drafts/issues/1428

  fantasai: What's going on is in the alignment spec we're saying we
            no longer do the overconstraint rules in CSS 2. Those
            are if you spec margin and padding and border and width
            on both sides. It's specified in CSS2.1 that margin box
            must fill containing block. If you specify all these
            properties it won't fit likely. 2.1 says you take end
            side margin and treat it as auto.
  fantasai: In alignment we're saying don't do that. When the margin
            box doesn't match the alignment dictates layout.
            Observably there's no difference. We spec the initial to
            be start alignment. dbaron pointed out we need to
            investigate situation with object model. Do you get the
            result of what was spec or what was used?
  fantasai: TabAtkins ran tests, it's mostly like the align spec,
            but there's no compat. We wanted to verify the group is
            okay with this override.
  <gregwhitworth> fantasai: I just added that Edge matches Chrome
  TabAtkins: Chrome always returns specified value for margin right,
             right or bottom. FF returns margin-right specified
             value, but fixed for right and bottom. I couldn't test
             other browsers at the time, but they're in the issue.
  gregwhitworth: I added, we match Chrome.
  TabAtkins: Great. Sounds like there was little matching 2.1. Let's
             resolve to let align overrule.
  Rossen: Okay, so let's match the spec to impl. Other opinions?
  Rossen: Objections to proposal?

  RESOLVED: Accept the proposal that margin and position properties
            will return the specified values.

  <TabAtkins> (Rather, not specified values, just *not* the result
              of the overconstrained-equation.)

Don't introduce baseline alignment to table columns
  Github: https://github.com/w3c/csswg-drafts/issues/1422

  Rossen: I think there was less compat on this.
  fremy: dbaron mentioned in alignment spec there's a line that says
         cell in a table sharing a column are in same alignment
         group if there's in the alternate writing mode of the
         table. Basically dbaron said it seemed difficult to impl
         and I agree so he proposed to remove this from align spec.
  fremy: It seems difficult to me to get the result, what dbaron
         said seemed right to me. At this point there's no browser
         that can handle vertical left right cells properly anyway
         so I think we can go ahead and baseline align.
  fremy: I agree with dbaron.
  dbaron: I think one other analogy is the complexity is similar to
          impl character alignment in tables. It's in substantially
          higher demand and also not implemented. Seems like the
          complexity is similar, but it would complicate things to
          do both. I'd rather character alignment happens first
  * tantek perks up and agrees with dbaron re: the complexity of
           character alignment (and non-implementation thereof)

  fantasai: I understand the priorities here. What if the spec said
            MAY so if an impl wants to do this they can.
  <dauwhe> +1 on priorities :)
  Rossen: One thing to point out is we had a similar discussion when
          working on grid for alignment of grid items and there we
          had a strong vote to not baseline align on the minor/block
  Rossen: Since baseline align is an inline concept trying to align
          to those is fairly tricky. When you throw this into the
          mix of all the sizing dependency I'd have to agree with
          dbaron that making this work and work interop will be a
          tall order.
  Rossen: I would side on not requiring this as an impl.
  myles: Everything you said is correct Rossen.

  Rossen: fantasai you seem to have been the one wanting to try and
          make this work. How strongly do you feel?
  fantasai: If the main concern is impl complexity I think it makes
            sense not to require. If there was an impl that decided
            it was important for their use case like if they have a
            lot of mixed writing modes then that impl should be
            allowed to do that without violating spec. I want to
            make this optional and we can make it clear we're not
            expecting impl but they're allowed to
  dbaron: You're saying make it optional but don't spec how it works
          since how it works changes the table algorithm pretty
  Rossen: I was also going to ask about making it explicitly
          non-defined rather than not allowing it would let the impl
          come back to the table. Could we make a way for this to
          work in all our frameworks. If we make it stronger it will
          give impetus to those impl that are violating to come back
          and say this is important and here is how it should work.

  Rossen: fantasai would you agree or prefer it to be in spec and a
  fantasai: I suppose that's fine.
  <fantasai> would put a note, then
  <fantasai> "This may be added in a future level if there is
             sufficient demand and implementer interest" ?
  Rossen: Other opinions?
  Rossen: Proposal: The baseline alignment in block direction of
          tables is not defined.

  RESOLVED: The baseline alignment in block direction of tables is
            not defined. Also add a note prompting implementors to
            bring back ideas if they have any.

Should 'left' and 'right' really both fall back to 'start?
  Github: https://github.com/w3c/csswg-drafts/issues/1403

  fantasai: dbaron pointed out that left and right fallback to start
            if inline axis is not in the axis we're aligning in. The
            spec could have been smarter on this, we have physical
            and line-relative left and right. Between the 2 there's
            an answer to what's left and what's right. There is a
            case of a completely horizontal document and align-self
            or align-content says left or right we don't have a way
            of saying if top or bottom is left or right. Spec says
            do start.
  fantasai: dbaron says left for top and right for bottom. I'm of
            the opinion this is error case and both should fall back
            to start. It's fairly arbitrary.
  fantasai: ?? commented that they would like to have no mapping.
            That's more or less equivalent to start. There's some
  <fantasai> e.g. whether or not to form a BFC

  Rossen: Proposal is fall back to start. fantasai explained why she
          believes this should be the case. Other opinions?
  dbaron: My general concern was it seems strange to have things
          called left and right that can end up on the same side.
  dbaron: It seemed like the case where you're likely to hit this is
          cjk where you author for vertical or horizontal and then
          decide to change it.
  Rossen: For floats left and right do we have similar?
  fantasai: No because we use the line-relative left and right.
  TabAtkins: I'll add that although you can come up with uses for
             left and right they were impl for being able to do
             legacy things. So it's okay for me if they're not great
             in some corner cases.
  <AmeliaBR> To be clear, we'd never have left falling back to right
             and vice-versa. It is about left and right both falling
             back to "top", correct?
  <fantasai> yes
  Rossen: True. Although all existing content is legacy
  TabAtkins: No, I mean the legacy keyword.
  Rossen: Got you
  fantasai: It's more. There are occasions where you want the
            physical direction.
  TabAtkins: We added it to support legacy keywords. You can use it
             other ways, but that was the original reason. We
             wouldn't have had left and right if we weren't trying
             to do legacy

  Rossen: dbaron would you be okay if we resolved to fall back to
  fantasai: We also could remove the keywords from align-self and
  dbaron: I'm okay with it.
  Rossen: What I hear is that we have generally seemed to be okay
          with falling back to start which doesn't mean it's great
          because you could have left and right map to the same
          thing. fantasai points out we make be able to revisit
          having these values.
  fantasai: We needed them for justify-content and -self. They were
            added...there were some cases where they would have
            meaning in align, but they're not critical.
  Rossen: I also think there are impl that are exposing those. Those
          are being used...removing left and right would be harder
          then fallack to start.
  fantasai: I don't think so. Majority of people aren't using left
            and right in a vertical axis. Unless you're using
            vertical writing modes there is no left and right on
            align-self and align-content because there is no left
            and right.
  Rossen: Perhaps.
  Rossen: What if we try to resolve on the fallback and then
          separately decide on keeping them. I'm not just trying to
          kick that down the road, but I want to see usage.
  Rossen: objections to: leave the left and right values to fallback
          to start.

  RESOLVED: Leave the left and right values to fallback to start.

  <tantek> I thought dbaron's point was an obj
  <tantek> no?
  <dbaron> I'm not objecting... I just thought it should be the
           other way.

  fantasai: Would it make sense to resolve to drop them? We can add
            them later.
  fantasai: I can't imagine a case where this is a compat problem.
  <tantek> fantasai: has a good point
  <tantek> wiser to drop now, reconsider adding in the future
  TabAtkins: Should be safe to re-add.
  <tantek> +1 fantasai proposal
  Rossen: I wouldn't be opposed. Let's make it a forcing function to
          those that have impl.
  Rossen: Obj to removing left and right from align tree?
  <fantasai> This would be to drop left/right from align-self and
  <fantasai> They would remain as part of justify-self and

  RESOLVED: Remove left and right from align-self and align-content
            in align L3.

Reconsider name of frames() timing function
  Github: https://github.com/w3c/csswg-drafts/issues/1301

  birtles: We introduced a new timing function where the difference
           is it includes both endpoints. It has a different name
           and different action so it counts number of steps. That
           made sense from usability point of view though it's
           different than step timing.
  birtles: There's two complexities. The timing functions in other
           content and other gradients which may need further
           variations. I'm wondering if we should extend steps or
           have something more familiar.
  TabAtkins: We should continue this on issue.
  Rossen: Thank you Brian for the introduction to it.
  Rossen: Please jump to the GH issue and give your feedback there.
  Rossen: Next Wednesday we'll resume with this.
  Rossen: Thanks Brian and please everyone give your opinion on the

  Rossen: That's it for today. Thanks for joining.
  <astearns> for those who missed the aside - next week's call is at
             the APAC-friendly time.
Received on Thursday, 29 June 2017 00:26:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 June 2017 00:26:39 UTC