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

[CSSWG] Minutes Telecon 2017-07-19 [css-writing-modes] [css-align] [css-display] [css-scroll-snap] [css-position] [css21] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Jul 2017 21:03:42 -0400
Message-ID: <CADhPm3vaZE3JLBncxLjoTijs7=JO39E=pYRaOK0g248ZOjKtRQ@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
-------------------

  - RESOLVED: Request updated PR for writing modes

Publishing an updated WD of css-align and css-display
-----------------------------------------------------

  - RESOLVED: Publish an updated WD of css-align
  - RESOLVED: Drop inline-list-item
  - RESOLVED: Publish new WD of css-display

Scroll Snap
-----------

  - RESOLVED: Accept this edit and close issue 1552 as resolved
  - RESOLVED: Make the change to page up and down to put in intended
              direction and endpoint class
  - RESOLVED: Take home and end out of intended direction class
  - RESOLVED: Updated CR for scroll snap

Computed value of float with absolute positioning when there is no
    box?
------------------------------------------------------------------

  - RESOLVED: Make the changes listed in css2.1 and position
             (Issues:
https://github.com/w3c/csswg-drafts/issues/1436#issuecomment-313215820
)

object-fit: scale-down should become a flag
-------------------------------------------

  - RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/1578

Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------

  - TabAtkins introduced the issue and indicated that they were
      leaning toward safe since it allows all the content to be
      reached.
  - However, it was discovered on the call that the usual fallback
      is unsafe so using safe would cause unexpected behavior.
  - There was value in both arguments, so discussion will continue
      on github in hopes of reaching a resolution next week.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0010.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Anton Prowse
  Matt Rakow
  Melanie Richards
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou

Regrets:
  Robert Flack
  Daniel Glazman
  Vlad Levantovsky
  Florian Rivoal
  Jen Simmons
  Greg Whitworth

Scribe: dael

  astearns: We have a meeting in less than 2 weeks.
  <tantek> wiki page URL?
  <Bert> https://wiki.csswg.org/planning/paris-2017
  <tantek> thanks Bert :)
  astearns: If you have not yet added your details to the wiki
            please do. And add items to the agenda so we can get a
            possible schedule in mind.

  astearns: Next, anything people want to add to the agenda?

Spec Rec next steps
===================

  astearns: Anyone have an update to share?
  <ChrisL> I just sent email seconds ago
  astearns: ChrisL sent an email seconds ago. There are updates for
            Fonts. Thanks.

  astearns: Is fantasai on yet?
  fantasai: I didn't do anything other than dealing with writing
            modes where I sent an update. There was a normative
            change, I pushed the change, complied DoC, sent to
            ChrisL.
  astearns: So things are with ChrisL?
  fantasai: ChrisL needs to figure out what's next to get published.
            I don't know what to do.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2017Jul/0012.html
  ChrisL: We were waiting on if we want to go to CR or PR. Seemed
          from the changes they were non-substantive, but fantasai
          thought it should be CR. I asked why.
  fantasai: There's a message linked in IRC. There's issue 1391.
            It's a substantive change, but quite minor. But I don't
            know what the state of the process is.
  <astearns> https://github.com/w3c/csswg-drafts/issues/1391
  <tantek> do test cases reflect the normative changes?
  <tantek> is it a breaking change?
  fantasai: I'd recommend a chat with Ralph to explain the changes.
            I think it's silly to CR first.
  ChrisL: That's listed in changes list?
  fantasai: Yes, and DoC.
  ChrisL: Great. I'll take that to Ralph.
  ChrisL: Thank you.

  astearns: Anything else on the set of specs we're trying to get
            updated to CR?
  fantasai: There's the list on the agenda for updating.
  astearns: True.
  Rossen: I believe there are tests stuck somewhere for review,
          maybe Flexbox or Grid. Might be good to have eyeballs on
          those.
  astearns: Are there people assigned?
  Rossen: I don't believe so.
  Rossen: Anyone can review tests.
  astearns: Let's look this week at what tests are waiting review
            and you and I can assign someone to review to get things
            moving.
  Rossen: Sounds good.

  * tantek notes that https://github.com/w3c/csswg-drafts/issues/1391
           has a test case and has changes to reflect implementation
           interop / consensus.

  tantek: Quick note on writing modes.
  tantek: I reviewed the issue and in my opinion I think we should
          go directly to PR. There is a test case and it's a change
          to reflect interoperable implementations so it's not
          breaking.
  * ChrisL wants what Tantek said minuted clearly
  <Rossen> +1 to tantek
  <ChrisL> thanks, t
  tantek: I just wanted to add weight to the PR request.
  <fantasai> thanks :)

  Rossen: Should we get a resolution ChrisL? If it's going to be
          worth the argument let's just call for consensus and move
          on.
  <ChrisL> sure
  astearns: proposal: request updated PR for writing modes instead
            of going back to CR b/c this change doesn't warrant
            going back to CR.
  <ChrisL> +1
  <tantek> because this particular change reflects reality (impl
           interop)
  <tantek> +1
  astearns: Obj?

  RESOLVED: Request updated PR for writing modes.

  <Rossen> yay!

Publishing an updated WD of css-align and css-display
=====================================================

CSS Align
---------

  astearns: Align- it's an updated WD.
  fantasai: Yep. We wanted dbaron approval on that since a lot of
            the issues were filed by him. If he's okay publishing
            now or wants more time to look.
  dbaron: I think there's more work to do, but I wouldn't object to
          a new WD. I went through the commenter response required,
          well, all but 3. There were 4 I marked as not satisfied.
  fantasai: Great. publish an update and keep working
  astearns: Objections to updated WD of css align?
  <ChrisL> that is an auto-publish, right?
  <fantasai> ChrisL, yes

  RESOLVED: Publish an updated WD of css-align

CSS Display
-----------

  astearns: Second is also updated WD of css-display. Looked like
            fewer issues.
  fantasai: Fewer, but quite a few. We could do 1495 quickly before
            publish. We should do an update and then keep working.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1495
  fantasai: Suggestion was inline-list-item is a little different
            than some of the others and do we really need this one.
            It might be worth dropping that unless someone has impl
            and wants to keep it.
  astearns: Anyone know if inline-list-item has been impl?
  Rossen: I don't believe we are.
  <fantasai> No hits in Mozilla's codebase
  astearns: Objections to dropping inline-list-item?

  RESOLVED: Drop inline-list-item

  astearns: Objections to new WD of css-display?

  RESOLVED: Publish new WD of css-display

Scroll Snap
===========

Clarify passing by requirement of scroll-snap-stop for different
    category of scrolling
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1552

  fantasai: We made some changes to clarify scroll snap stop in
            respect to different types of scrolling. New definition:
  <fantasai> When scrolling with an intended direction, the scroll
             container can “pass over” several possible snap
             positions (that would be valid to snap to, if the
             scrolling operation used the same direction but a
             lesser distance) before reaching the natural endpoint
             of the scroll operation and selecting its final scroll
             position. The scroll-snap-stop property allows such a
             possible snap position to “trap” the scrolling
             operation, forcing the scroll contain[CUT]
  <fantasai> Values are defined as follows [...]
  <fantasai> This property has no effect on scrolling operations
             with only an intended end position, as they do not
             conceptually “pass over” any snap positions.
  fantasai: What we decided was it has no effect on a scroll that
            has an end point but no direction. That includes scrolls
            where you jump to an element or if you are driving or
            panning and let go at that point as you're dragging.
  fantasai: Things with a direction like down arrow and page down
            and momentum scroll are tracked by scroll-snap stop.

  astearns: And I see one comment liking the wording.
  fantasai: MaRakow looked it over and sent some comments. We
            replied. That was offline.
  MaRakow: It seems generally fine. Main thing interesting is the
           previous language talked about container, it seemed,
           though it was in the section about elements. I'm
           generally fine with the definition unless [missed]
  astearns: Anyone else have an opinion?
  astearns: Objections to closing this issue as resolved?

  RESOLVED: Accept this edit and close issue 1552 as resolved

Classify pageup/pagedown keys
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1605

  fantasai: We realized that page up/page down keys didn't have a
            classification so we proposed adding them to the
            intended item since it's basically understood to be a
            screen scroll.
  TabAtkins: We added home and end too.
  MaRakow: I think page up and down make sense. Home and end are
           more challenging since with the previous resolution end
           might not get you to the end and most people expect home
           or end regardless of scroll-snap-stop.
  * tantek agrees
  <tantek> home/end set expectation of actual top/bottom
  fantasai: That's a really good point.
  fantasai: One thing I would consider there is I think we put home
            & end under another classification originally...let me
            look that up. I could see an argument for hitting
            scroll-snap-stop because we have these internet things
            where you want to get to the end of an article and it
            just loads another. I'm okay moving them into the
            intended end.
  TabAtkins: I'm okay either way.
  <Rossen> +1 to keeping home/end sane

  astearns: Draft has home and end in different group?
  fantasai: Page up & down
  TabAtkins: Direction + end point
  fantasai: We can move to intended position.

  astearns: Is there any objections to making the change to page up
            and down to put in intended direction and endpoint class?

  RESOLVED: Make the change to page up and down to put in intended
            direction and endpoint class

  astearns: And we'll take home and end out of intended direction
            class?
  astearns: Objections?

  RESOLVED: Take home and end out of intended direction class

Publication
-----------

  astearns: Anything else before we update CR for scroll snap
  ChrisL: I sent a question about impl status. According to caniuse
          it's fully implemented in safari and partially by FF and
          Edge
  TabAtkins: It's all an incompat subset of the old spec.
  <leaverou> btw this is the caniuse URL
             http://caniuse.com/#feat=css-snappoints
  <leaverou> it does mention support is partial
  ChrisL: Does that mean the browsers have tests is where I was
          going. Transition request needs to say impl status.
  TabAtkins: We're nearly finished with our impl. I'm sure we have
             tests. I can poke Majid to see about grabbing them.
  ChrisL: That would be great. Anyone else have tests?
  Rossen: For scroll snapping I think the current version isn't
          compat with the spec. We have tests but they're for the
          old version so not very helpful. I would encourage anyone
          with current test to contribute.
  Myles: We have tests but they're old.
  <ChrisL> ok I will send a transition request

  astearns: This needs to get on our list of spec rec next steps to
            get a test suite.
  astearns: Anything more ChrisL?
  ChrisL: No unless there's been additional wide review to mention.
          Apart from that I'm good to go.
  astearns: Has anyone outside the WG looked?
  TabAtkins: Aside from some impl I don't believe so.
  ChrisL: I meant since Oct last year.
  astearns: I don't believe we've sent it outside the group.
  ChrisL: Okay. We did it when we first went to CR. It's in case
          there was anything else.

  astearns: Objections to updated CR for scroll snap?
  <ChrisL> +1

  RESOLVED: updated CR for scroll snap

Computed value of float with absolute positioning when there is no
    box?
==================================================================
  Github: https://github.com/w3c/csswg-drafts/issues/1436

  fantasai: The issue is about if display has value of none. 2.1
            rules say position and flow don't apply and this short
            circuits the rest of display computations. Normally if
            you have position: absolute and float: left float
            computes to none. If you have display:none the
            computation doesn't happen. However, this becomes
            interesting with display: contents. What do we do for
            that one?
  TabAtkins: This is where display: contents is the same problem as
             none, it's just someone is more freshly looking.
  fantasai: Anything with display: none due to its parent the float
            computes to none. We propose any element with display:
            none, child of display: none, or display: contents they
            all behave the same in respect to these transformations.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/1436#issuecomment-313215820
  fantasai: We proposed specific edits in the issue ^. We'd like a
            resolution to make them consistent and then a second for
            people to review the proposed edits.

  dbaron: Idea is you make them consistent by always applying the
          rule where if position is absolute float is none?
  TabAtkins: It's bad that it's inconsistent.
  Rossen: We already do...in all cases we would apply the rules and
          it seems FF and Chrome from reading the issue have a half
          and half where you do it for display: content but not
          display: none so you have branching somewhere.
  dbaron: I'd be hesitant to have special rules for descendants.
  dbaron: But I'd be okay to make them all float: none
  Rossen: There shouldn't be any special casing for descendants. I
          was highlighting that in this case you're not going to
          apply float computation rules, but with display: contents
          you will. If we all align and make it always apply then it
          will be more internally consistent and interop.
  TabAtkins: It matches IE always and Chrome & FF except in cases
             with display: none. Always applies is a small change.

  Rossen: I'm fine making the changes to css position. fantasai you
          said there might be changes to css 2?
  Rossen: Or is it css display?
  fantasai: Yes for css2. There are edits in the issue. It would be
            good for someone to check those
  Rossen: I did check, but those edits appear in css2.1 section 9.7
          and in css position. I can reflect the position changes.
          Question is do we need to do anything on css-display?
  TabAtkins: I don't think so. Algorithm is only in 2.1 and
             position. There's nothing special in display.
  Rossen: Sounds good.

  astearns: Sounds like we need to resolve to make edits in css
            position. Would it make sense to make the edits, round
            of review, and then backport to css2?
  TabAtkins: We were operating off 2.1 algorithm so we know what
             needs to be changed.
  astearns: So we'd resolve the change for both position & 2.1
  TabAtkins: Yeah.
  astearns: Objections?

  RESOLVED: Make the changes listed in css2.1 and position

CSS Display
===========

  <ChrisL> we resolved to request CR on css display in February. Is
           there some issue with the disposition of comments of the
           transition request? bert was handling it
  astearns: [reads ChrisL in irc]
  fantasai: We resolved to publish display. Between resolution and
            prep transition request Oriol filed a ton of issues and
            we decided not to publish until we addressed those
            issue. We now have except a few on the F2F agenda. We
            can fix those and try again on CR.
  ChrisL: Thanks. Good to know.

  TabAtkins: I suggest we defer #8 reconsider name of frames()
             timing function since we're still not at a stand still
             on GH.
  astearns: Can you remove agenda+ tag?
  TabAtkins: Can do.

object-fit: scale-down should become a flag
===========================================
  github: https://github.com/w3c/csswg-drafts/issues/1578

  leaverou: Currently scale-down is defined as contain or none. If
            contain would result in enlargement it's treated as same
            as none. This was defined at time cover was rare. Today
            we have a lot of images that are treated to cover the
            entire background. I'm sure you recognize this, we see
            it over the web. The scale-down behavior would be
            useful, but it's defined as contain or none.
  leaverou: It's unpredictable that it's defined that way based on
            the name. I suggested scale-down becomes a flag used
            with cover or contain. When it's on it's own it can be
            defined as contain for legacy.

  leaverou: I discussed with fantasai and she agreed. We wanted to
            run by the group.
  TabAtkins: Sounds reasonable to me.
  astearns: Other opinions?
  astearns: Doesn't seem like there's a backwards compat because we
            can define scale-down by itself.
  iank: Is there a github?
  astearns: Yes. 1578
  <leaverou> https://github.com/w3c/csswg-drafts/issues/1578
  <rachelandrew> I think this would be useful behaviour.
  astearns: I'm not hearing objections. Lots of positives.

  RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/1578

  astearns: We made it through the agenda.
  TabAtkins: fantasai has issues we could add.
  [debate over what to do]

Should last-baseline's fallback alignment be safe or unsafe?
============================================================
  github: https://github.com/w3c/csswg-drafts/issues/1611

  TabAtkins: Fallback alignment is used in 2 cases. If you try and
             use baseline alignment but the element isn't in a
             context to do any baseline aligning it doesn't have a
             size it can baseline align. It uses fallback. Other is
             after you've done the baseline alignment you then align
             the group according to your fallback alignment.
  TabAtkins: Problem is with an end alignment, do we use safe end or
             unsafe end? There's arguments on both. It's better to
             shift down when it's too small then to lose part of the
             content. I don't believe there's a strong author intent
             to go into the unscrollable. I think it both cases it's
             better to do the safe end alignment.
  astearns: What's the difference between safe and unsafe?
  TabAtkins: If container is smaller than element end alignment
             aligns to two edges and you could get unscrollable.
             That's unsafe. Safe is if it happens we switch to start
             alignment so it scrolls down.
  astearns: Got it. Seems reasonable.

  Rossen: Last time we decided we fallback to end if we do last
          baseline. In an overconstraint now it's start?
  TabAtkins: This is unrelated. It doesn't trigger in the same cases
             as discussed last week.
  Rossen: Why not?
  TabAtkins: Last week we were dealing with a stretching element
             forced by a max width to be too small. This is things
             larger than the container. It's a different set of
             elements.
  fantasai: Also it effects everything...you could interpret it 2
            ways. 1 is we break alignment so if it overflows and the
            other doesn't we don't overflow. Or they continue to
            align and they both overflow and then do they align to
            bottom or top.
  fantasai: Other was just about one item and how it relates.
  <astearns> start and end rather than bottom and top
  Rossen: And this is because we fallback on end and we don't have
          the problem with first because we fallback to start.
  Rossen: Got it.
  <dbaron> I support Tab's proposal here.

  Rossen: Do we have any other cases where combination of end and
          unsafe is the default?
  TabAtkins: I don't think anything else falls back to end.
  Rossen: Even in explicit end the default is safe?
  TabAtkins: Determined by layout mode.
  Rossen: Now if we have something fallback to end would safe and
          unsafe be based on layout?
  fantasai: I think we changed it so everything is unsafe by
            default. This is a fallback to it's different.
  Rossen: Now I'm starting to be less okay because we'll have cases
          were I forgot one property and half my items shift in
          weird ways and I don't know why.
  TabAtkins: We're not proposing a control, so it's not leaving off
             anything. You shouldn't make that decision because it's
             a secondary alignment where the one you spec doesn't
             fully apply.
  Rossen: What I'm saying is I'll have two items, one last baseline
          one end. In which case the one with last baseline it does
          fallback to end. If we're not overconstraint they look
          same. As soon as you're overconstraining one becomes
          scrollable and one not scrollable directly and that's
          weird and people will be confused.
  Rossen: That's why I wanted to walk back from the behavior of the
          explicit end or start and what kind of safe/unsafe
          handling we have there.
  fantasai: That's a fair point.
  dbaron: You can specify safe start and safe end. It's saying
          fallback for last baseline is safe end.
  TabAtkins: Yeah.
  Rossen: What I'm trying to say is if we made the explicit decision
          that everything fallback mostly to unsafe, why make an
          exception? If that's not the case maybe we revisit the
          fallback to unsafe, but I don't see why to do that.
  TabAtkins and fantasai: Can't change unsafe fallback,

  Rossen: We have the fallback to go back to end, can we try and do
          unsafe there and see if we have to change later with impl
          feedback?
  TabAtkins: Without any way to change safe/unsafe (and we're not
             proposing a control) there's no way to get the other
             and the one value we can expose should be the one that
             guarantee to not hide content.
  astearns: I'm confused why it's better for this case but not the
            default.
  TabAtkins: We already had centering and alignment based on margins
             in flexbox and that was safe. We made them do the other
             behavior to let you get them. When we moved to
             alignment we felt it would be useful to allow a control.
  astearns: It's just historical and backwards compat constraint.
  TabAtkins: Maybe. I don't think it was unreasonable for flexbox to
             default to unsafe because there was a control for safe.
             Baseline alignment can't mimic itself with margins. We
             either have to expose a toggle or make a choice and I'd
             like to avoid syntax complexity of a toggle for this
             edge case.
  astearns: I can see both sides. I like that it will default safe
            so in this edge case you won't lose content, but since
            it's a tiny edge case I can see keeping it same as the
            other default alignment.
  Rossen: I'm going to be okay with either. I wanted to point out
          consistency is always good. But I see losing content as
          bad as well which will happen with explicit end already.
  astearns: We're out of time. I suggest we let log bot put this in
            the issue, let it sit for a week, and decide next week.
            If there are additional thoughts please add to the
            issues.

  astearns: Thanks everyone for calling in.
Received on Thursday, 20 July 2017 01:04:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 July 2017 01:04:37 UTC