[CSSWG] Minutes Telecon 2016-08-17 [css-align] [css-grid] [css-flexbox] [css-scroll-snap] [css-tables]

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[CSSWG] Minutes Telecon 2016-08-17 [css-align] [css-grid] [css-flexbox] [css-scroll-snap] [css-tables]

Dael Jackson
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

September and January F2Fs

  - Rossen asked group members to ensure that the proposed dates for
      January are clear so he can finalize plans.

Wrong assumptions about baselines only occurring in the inline axis

  - RESOLVED: Remove baseline from the block-axis as a way to align

Sizing grid items

  - RESOLVED: Stretch items the same way we do for non-replaced

Scroll Snap

  - There was some concern that content re-stabilizing not being
      defined in the spec will prevent testing.
  - RESOLVED: Accept the changes proposed here:
              Make sure that if the UA evaluates and thinks it
              shouldn't re-snap it's not required to do so,
              potentially by merging the first and last sentences in
              the paragraph.
  - Though everyone agreed on the problem space, there were concerns
      about the proposal to turn scroll-snap-padding into snap-
      padding. Some of the concerns raised were:
      - The proposal wasn't intuitive for authors.
      - The proposal was trying to solve too many use cases to be
  - The discussion will continue on the github issue to continue
      resolving concerns.
      - fantasai emphasized that this needed to happen quickly to
          keep this from holding up the spec.

Synthetized baselines seems like a breaking change

  - RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/373
              as no issue.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0051.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Alex Critchfield
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Peter Linss
  Thierry Michel
  Michael Miller
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  Liam Quin
  Matt Rakow
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Tantek Çelik
  Daniel Glazman
  Edward O'Connor

September and January F2Fs

  Rossen: It's 9:03PT. Hello everyone. Are there any last minute
          items to discuss?
  <jensimmons> This is off topic, so I’ll drop it here & not say it
               aloud, but I wanted to share this article that I
               wrote on Feature Queries:
               There’s not been much written about how to use
               @supports yet… this should help teach people what it
  <TabAtkins> Is good article.
  <jensimmons> thanks TabAtkins
  <zcorpan> (I earlier today Agenda+ed
             - didn't know if it was on the actual agenda or not yet.
             but happy to discuss it next week or discuss in the
  fantasai: I wanted to do the airBnB. Reply now so Florian can sort
            it out.
  Rossen: Yep. Is there anything else before that?
  Rossen: Then I want to add the Jan F2F as well. Go ahead Florian
          and fantasai.

  Florian: There's 3 people from Japan coming on top of me. So I
           booked a place. I had no info from anyone else then.
           There's one more, I'll check the number of beds.
  fantasai: Do you have space for zcorpan?
  Florian: I may. I'm not sure if I have enough without sharing beds.
  fantasai: zcorpan and plinss replied on the thread.
  Florian: I booked before that. I'll check. I may have 1, likely
           not 2.
  Rossen: Anything else on this? Or can it go back to the mailing
  Florian: Yep. I'll follow up there or privately.
  Rossen: Thanks for organizing that.

  Rossen: Reminder on the Jan F2F. I'm looking at locations. Our
          current schedule has Jan 11-13.
  Rossen: Please go to your calendars and verify this isn't
          something that's a hard conflict with anything else before
          I make final arrangements.
  * fantasai will know January schedule hopefully by next week
  Rossen: I'm trying to see if we can locate in Seattle itself. If
          not we'll be in Redmond.
  <smfr> +1 for seattle
  Rossen: That's all on F2F.

Wrong assumptions about baselines only occurring in the inline axis

  <Rossen> https://github.com/w3c/csswg-drafts/issues/197
  fantasai: Mats pointed out we define block-axis baselines and
            there's restrictions on how they applied so he filed
            issues to remove them. In the process of trying to do
            that...we checked in a bunch of changes and fremy was
            concerned. Last week we talked about a bunch of this
            stuff and came up with reason it won't work. So proposal
            is remove them so baseline can only be in inline axis. A
            grid could do alignment in a column, but the actual
            container can't have block-axis.
  fantasai: Reason is, for example, you have a column in a grid or
            table and the first is horizontal table or grid that
            have vertical text. In theory that could have a baseline
            on the right or the left. On the next two rows have have
            one vertical-lr and one vertical-rl and they don't align
            to each other. What happens to the horizontal element?
  fantasai: This is a nonsensical situation. It seems this would end
            up being arbitrary and there's a bunch of complications.
  fantasai: Proposal is baselines can only exist in inline axis of
            the box and make sure all boxes have a baseline.

  Rossen: I'm in support of this. I agree we should keep the inline
          concept inline and not introduce in the block direction.
  Rossen: I won't repeat everything, but we support backing out of
          that feature.
  Rossen: Additional comments? Questions?
  * fantasai pings TabAtkins for comment

  Rossen: fantasai did you want a resolution?
  fantasai: Yes.
  Rossen: Objections to removing baseline from the block-axis as a
          way to align?

  RESOLVED: remove baseline from the block-axis as a way to align

Sizing grid items

  <Rossen> https://github.com/w3c/csswg-drafts/issues/283
  <Rossen> https://github.com/w3c/csswg-drafts/issues/394
  fantasai: There was an issue filed a while back on the implied
            size and how that interacts with fixed size track. We
            concluded fixed size should reduct the auto-min.
  fantasai: That caused me to take a closer look and we're not super
            consistent on defining sizing for grid items. So what
            should we do? Based on flex containers it seems they
            should be doing a value that's stretched and we do the
            replace for the fit and resolve the auto thing.
  fantasai: If there is content bigger than the grid item it won't
            stretch to fit, it'll stay in the track. And we want
            that in both dimensions. The reason is the authors set
            an explicit size on the track. It seems more likely the
            way is to stay in the track by default. It's also to be
            consistent with the lines in flex that operate in the
            cross axis.
  fantasai: Main axis flex does something different where we can
            overflow and the items stack. One of the reason we use
            auto-min is to make the content readable for the user.
  fantasai: That approach's usability depends on the items moving
            down and not overlapping. In fixed size you get the
            overlapping. The model is more consistent with flex in
            the cross axis.
  fantasai: Talking with Microsoft that's what they implemented
            which has some author feedback. So clarify the spec and
            resolve contradictions in favor of for stretch items use
            the non-replaced block formula.

  Rossen: Thanks for the summary. Comments? Suggestions?
  Rossen: So we have a proposal: Stretch items the same way we do
          for non-replaced.
  Rossen: Objections?

  RESOLVED: Stretch items the same way we do for non-replaced

  Rossen: fantasai you'll make the edits?
  fantasai: Yep.

Scroll Snap

Re-snapping requirements

  <Rossen> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-resnap
  fantasai: We skipped one of the San Francisco differences. You can
            read it here^. I could read it out load, but best way is
            to give people time to read an than type +1, -1, or 0
            into IRC.
  fantasai: Reasonable?
  Rossen: Yep. Let's cap it at 2 minutes.
  * Florian read it, sounds good. +1

  smfr: I think someone will have to implement to know if it's the
        right thing. We'll have to do this by feel.
  fantasai: We're doing it, but this is cleaning the prose.
  smfr: Does any implementor do re-snapping?
  fantasai: No, but the spec requires it. I'd rather fix the prose.
            If we find problems we can file issues.
  Florian: Until then we need to be consistent.
  fantasai: If you don't like the section that's a separate issue.

  MaRakow: This is only editorial, not functional, right?
  fantasai: I think there is a somewhat substantial change in bullet
  MaRakow: What would be the functional change resulting from that?
  fantasai: I think its...it's matching a resolution from Jan 20th.
  MaRakow: It sounds like all you're doing is putting the
           duplication of text in one place.
  fantasai: Yeah. [reads]
  MaRakow: I see.

  Florian: This is somewhere between editorial and normative where
           the previous was too ambiguous?
  fantasai: I don't remember.
  Florian: I like it.

  MaRakow: The "must be re-snapped" might be the most interesting. I
           don't know if for proximity that's always right.
  fantasai: The model is there's valid places to be and not valid
            places. The proximity can change based on distance and
            speed, but this is saying that the user very slowly was
            holding the scroller over a scroll offset and waited for
            a while before letting go. If scroll would then be
            adjusted the equivalent adjustment should be made when
            user isn't scrolling but content has moved so we're in
            the same position.
  fantasai: So the content and scroll position moves until it's
            stable and we see if we snap or not. That's evaluated
            the same as the user doing a precise drop. If not script
            could get you into a position the user couldn't get to.
  Florian: I think the spec is loose. You're not strict on heuristic.
  fantasai: We are.
  Florian: Within explicit scroll there may be other heuristics.
  fantasai: That's fine. An explicit scroll is I want that position
  Florian: And if on top of that there's other heuristics they can
           continue to apply. So be smart but do something. Am I
           reading right?
  fantasai: The script cannot get into a position the user can't.

  MaRakow: Right now it's phrased as re-snapped. Maybe what you're
           going for is must reconsider snap points in the case
           where they would be if the scroll was to that position.
  fantasai: I see. We're using re-snap and that implies we snap to
            the previous. But there's no previous in this case. I
            can say UA must reconsider snapping. I'll fix that.
  fantasai: Take all these changes and "must be re-snapped" to "must
            reconsider snap positions"
  Florian: I think the last paragraph has a clarification of that.
  fantasai: I don't know.
  Florian: 2nd green highlight in the last paragraph.
  fantasai: Yeah. That's fixed there.
  Florian: [reads]
  MaRakow: I think it's both. It's trimming the final sentence in
           the 3rd bullet point. I think the last bullet is the
           proposed final text.
  fantasai: Let me re-evaluate.
  fantasai: It looks like last and first sentence should be merged.
  MaRakow: Yeah.
  Florian: I'm hearing we agree about the content and some editorial
           concerns. Can we resolve to do it and leave it to the
           editors for phrasing?

  MaRakow: I have another issue. I think you're right about merging
           the sentences. Sounds probably right.
  MaRakow: Other thing is the statement about content re-stabilizing.
           Is that well defined?
  MaRakow: I think I know what it means, but is there a definition
           to link off to?
  fantasai: We don't have an official definition. I'm not sure if we
            want to. UA is trying to figure out batching changes.
  Rossen: How to test without it?
  fantasai: It's obvious that it's stable if it's not changing in a
            large chunk of time. If there's changes 2 ms apart the
            UA might not re-snap. We don't want to be overly precise.
            We can assume 1 sec of not moving is enough.
  MaRakow: That's different than I thought. I thought I was during
           script execution you wouldn't re-snap.
  fantasai: It's up the the UA. That's all up to them. As long as
            it's not a long chunk of time where it sits there for a
            while and then snaps is unacceptable. We can come up
            with reasonable for testing, but pinning it down depends
            on heuristics the UA might want to tweek.
  MaRakow: I'm wondering if there should be a firm lower bound where
           you don't re-evaluate sooner than X.
  <gsnedders> I'm going to point out that manual tests are almost
              never run.
  fantasai: I don't think we need that. I don't think interop on the
            same time is important. I think it's what the tester
            feels is a reasonable limit. If a UA fails and disputes
            that it fails we can re-discuss. I don't think that'll

  liam: You need text that with content-editable you shouldn't
        scroll while someone is typing.
  Florian: That's part of the next thing on the agenda
  Rossen: So back to this one to try and close.
  <liam> [oops]

  Rossen: What is the proposed resolution?
  fantasai: To accept the changes, make sure it's clear the UA isn't
            required to re-snap, it's not supposed to re-snap. Make
            it clear that if the UA evaluates and thinks it
            shouldn't re-snap, it's not required to do so.
  Rossen: Okay.
  Rossen: Sounds good to me. Do we have objections?
  MaRakow: Also merge the first and last sentences.
  fantasai: Yeah. And we can tack onto the resolution "by
            potentially by merging the first and last sentences".
  Rossen: You okay MaRakow ?
  MaRakow: Yeah.

  Rossen: Other comments or objections?

  RESOLVED: Accept the changes proposed here:
           Make sure that if the UA evaluates and thinks it
           shouldn't re-snap it's not required to do so, potentially
           by merging the first and last sentences in the paragraph.

scroll-snap-padding vs scroll-padding

  <Rossen> https://github.com/w3c/csswg-drafts/issues/395
  <fantasai> https://github.com/w3c/csswg-drafts/issues/395#issuecomment-239995319
  fantasai: I dropped a link to the proposal. Basic issue, scroll
            padding helps with when you want some breathing room
            between content and viewport or you want to exclude some
            area of the viewport because there's something to avoid.
            So you're snapping the items in a smaller area.
  fantasai: Turns out a lot of operations need the same behavior.
            Like navigating to a fragment id. So you shouldn't bring
            it into the viewport because the author told you to
            exclude it. Even when we don't have a snapping viewport,
            we would want this kind of control where the author says
            exclude this area. Operations that involve the area
            navigate to a fragment ID. If the user tabs through form
            controls and something is off screen the UA will bring
            that into the viewport.
  fantasai: Page up and page down when you're excluding a header and
            you want to exclude that so that content doesn't go
            under. There's a lot of use cases.
  fantasai: We can solve all of them with scroll-snap-padding. It
            needs a rename to something like scroll padding. It
            would solve all this declaratively. It would allow
            authors to stop hacking scrolling on this type of page.
  fantasai: The UA can create a better experience when the author
            can give this info. Proposal is rename to scroll-padding
            and have it solve all these cases.
  fantasai: No effect on layout or scroll origins. So we're not
            changing meaning, we're just allowing the UA to use it
            for more than snapping.
  Florian: Two things to add. It effects fantasai's cases with no
           snapping. It also effects scroll snapping because if you
           have...we defined explicit scrolling when you bring
           something to a point. There's a few operations that
           combine scroll into view and than snap which isn't
           explicit scrolling.
  Florian: If you tab to something you scroll to bring the focused
           button into the area and than you snap. It's a combo of
           the effects.

  <Rossen> https://sketch.io/render/sk-046db1469a67b75d62773ad88383a1ed.jpeg
  Rossen: I mentioned this to fantasai when she visited. My concern
          is by default the feature kind of doesn't work. If you
          look at that sketch I shared: if you have no padding by
          default and let's assume it's a block. Since we don't have
          regular padding the content origin is 0,0.
  Rossen: Your scroll-padding, let's say it was defined as top: 2em
          then the feature doesn't work because you'd have to
          reposition the origin of the content.
  Rossen: Also going to be odd cases with scroll padding and scroll
          top butting against each other creating scrollable area 0.
  Rossen: I can poke many holes into this proposal.
  fantasai: I think it is important for scroll padding to be
            independent and not interfere with layout. Authors may
            intentionally put stuff in the scroll padding. They're
            responsible to make sure the visible content is where
            they want it to be. It should just be for padding not
            for layout.
  fantasai: I don't want to tie them together
  Rossen: I totally agree. Scroll padding shouldn't effect layout.
          I'm trying to say the feature itself is already becoming
          seemingly broken when you don't align the layout so it
          works the way it should according to scroll padding.
  Florian: I don't think so.

  MaRakow: To echo Rossen I think there's a lot further
           considerations. The problem you want to solve is there's
           a lot of scrolling mechanisms that have crappy results
           and it's an interesting problem. I think the scrolling
           mechanism you called out are diverse enough that I don't
           think there's a single approach.
  fantasai: I don't think we can solve everything, but telling the
            UA the scroll padding gives the UA the information it
            needs to do something smart. For example focus will
            bring something into view, but it won't snap or scroll
            unless the author requests. The scroll padding tells the
            UA the area you consider the focus.
  MaRakow: To finish my thought, I think there's an interesting idea
           to declare a suboptimal region for content, but it needs
           thought on interaction. For example I think you said this
           is scrollers with a non-snapping scroller. But when it's
           not none we need to answer how it interacts with snap
           points. Also cases when snap padding can't be satisfied.
           There's open questions.
  MaRakow: It's a question also if it's a guarantee it'll come into
           view or a hint to the UA.
  MaRakow: If it's the latter I'm not sure overlapping with a
           feature that controls scroll offset is right.
  fantasai: When you can't get to the position we should treat it
            like a snap position you can't get to. I think that's
            straightforward. The UA should try and put something
            into view, but it might not be able to do that because
            the scroll area isn't big enough or if there is some
            snapping restrictions that would restrict the UAs
            ability to put the element into the snap port.
  fantasai: Just as we didn't have scroll padding and we had to
            bring the thing into the viewport.
  fantasai: [missed] I think this can be precisely defined and the
            snapping interaction is straightforward.

  Florian: I'll reply to Rossen first and the diagram. If you don't
           consider regular scrolling, but snapping and snap
           scrolling you have the same problem. If it's positioned
           somewhere you can't scroll to you have the same problem.
           If the author puts things into the area that's not
           reachable you won't be able to go there.
  Rossen: I'm talking about default behavior. This is a default
          behavior that you'll get if you don't have padding.
          Putting an element that's beyond scrollable is an edge case.
  fantasai: Right now there's the same problem. You get the same
            problem and it's not a new issue. It's how these
            properties in general work.
  Rossen: Snapping and not being able to snap is one thing. Putting
          a banner on top of a box and assuming that scrolling will
          adjust so all text is visible is confusing. Padding
          suggests that you'll have padding from your position.
  fantasai: It's scroll padding. Authors are solving this now.
            They're hacking scroll events because they can't solve
            the scrolling piece, but they already have control over

  Florian: In response to MaRakow about many things effected, I
           agree there's quite a few and they're different, but
           they're unified because they're all the things where the
           user, whether they're moving by tab or whatever, there's
           an implied request for scrolling without a coordinate. In
           all these cases the UA has rules to decide where to put
           the element. That's the shared characteristic. The user
           asks for something the results to a scroll somewhere in
           the viewable area.
  Florian: This says you should only consider the area reduced by
           the padding.
  Florian: All the heuristics you do keep doing it. Just consider
           the smaller area.
  Florian: How this interacts with snapping. Instead of the user
           giving an explicit coordinate, the user requests the UA
           to pick some coordinate in the area. Then you use the
           normal. This gives an extra step to consider the padding
           when picking a coordinate. After that it's the same thing.
           The UA picks, it's just an extra consideration.
  Florian: All mechanisms say pick something viewable in an area.
           We're restricting the area.
  Florian: I'd like to argue a bit more on our point, but we can go
           to the queue.
  Rossen: We can take that to the issues.

  MaRakow: I mostly wanted to echo that it's more productive to go
           back to the issue. It's an interesting problem, we need
           to talk through approach.
  Rossen: I agree. I'm not trying to shoot down the problem or
          solution, I want something more intuitive.
  fantasai: We should wrap up this spec before TPAC. No reason to do
            that except if people want to think about it that will
            hold it up. Let's try and get to a point where we can
            vote soonish, not in 6 months. Or we try and add it and
            work out issues.
  Rossen: I would prefer to take it to the issue and if there's no
          traction by next week we want add it and force the issue
          in the spec. How does that sound?
  fantasai: Yeah. I just want this to not be let's think about this
            cute idea... maybe under the cherry blossoms next May.

  Rossen: Florian I see you're on the queue, I want to finish and
          move on.
  Florian: Short point. If we add this change it removes the need
           for a proposal from TabAtkins about sticky snapping.
           There is maybe extra complexity here, but drops other

  Rossen: 2 minutes left. Anything we can do in that time?
  Rossen: [read them]

Synthetized baselines seems like a breaking change

  <Rossen> https://github.com/w3c/csswg-drafts/issues/373
  fantasai: I think for baseline alignment the conclusion was we
            keep synthesizing baselines for everything.
  Rossen: So we can close this issue?
  fantasai: I believe so unless TabAtkins has something?
  TabAtkins: It's fine. I have nothing to say.
  Rossen: You're fine closing this no issue?
  TabAtkins: Yep.
  Rossen: Objections?

  RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/373 as
            no issue.

  Rossen: We're top of the hour. Let's call it a day and we'll move
          the remaining items to next week.
  Rossen: Thank you everyone.