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

[CSSWG] Minutes Telecon 2016-05-25 [css-grid] [css-text] [css-overflow-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 25 May 2016 19:31:24 -0400
Message-ID: <CADhPm3sX2v8x5jWbx_VpTnXyG5AKF2DtJY=QCNy6hBNwYC27zg@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.
=========================================


Grid
----

  - RESOLVED: The grid-template and grid-gap properties have no
              effect on a sub-grid
  - Tentatively the group resolved that auto-repeat should be
      invalid despite existing implementations. And remove the
      grammar that allows repeat() for columns as it was an accident.
      - If there are no objections on the mailing list before the
          next telecon, the group will formally resolve.
  - TabAtkins asked anyone interested in the algorithm to review
      section 12.1, issue #8
  - RESOLVED: Take the clamping behavior for error cases on subgrid
              where items are outside the subgrid (issue 4).

What level should break-spaces go to
------------------------------------

  - RESOLVED: Add overflow-wrap: break-spaces to level 3

Overflow
--------

  - TabAtkins brought to the group that the spec and implementations
      disagree on behavior for when a scroll container with overflow
      auto or scroll and padding on all sides: does the padding on
      the end edges get included in scrollable area?
      - In the block direction some implementations do show padding
          and it was generally agreed that that is the author
          expectation.
      - There was a lot of concern in changes breaking web compat,
          especially in the inline direction as no specs do that.
      - TabAtkins proposed amending the spec to say that padding
          should be respected in the block direction and noting the
          issue around the inline direction which would encourage
          people to note breaking behavior around that or make test
          implementations allowing it.
      - Conversation will continue on the mailing list.
  - RESOLVED: Publish a new WD for overflow

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016May/0213.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Michael Miller
  Anton Prowse
  François Remy
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Chris Lilley
  Edward O'Connor
  Lea Verou

Scribe: dael

Grid
====

  Rossen: Let's get started.
  Rossen: First agenda item, any additional items?
  [silence]

Reduced Subgrid Proposal - 1-axis subgrid
-----------------------------------------

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0196.html
  TabAtkins: So we roughly discussed it...
  TabAtkins: We discussed it at the F2F. This is...a somewhat open
             question at the F2F is subgrid doesn't pay attention to
             grid-template-rows and grid-template-columns. We may in
             the future want to do one axis subgrid. The question
             was if we should have that future switch be existent on
             a non-none grid-template-rows.
  TabAtkins: After discussion we decided the idea that we could
             depend on that being a safe upgrade path in the future
             was not realistic. We'd see a bunch of pages broken by
             this. So we decided that if we do 1 axis in the future
             we'll do it through new syntax. New grammar or a
             display value that's very distinguishable.
  TabAtkins: Therefore the properties that grid doesn't pay
             attention to do do nothing.
  TabAtkins: That's the thing we're doing and we thought we should
             get approval.
  <frremy> TabAtkins fantasai: looks good to me
  fantasai: The case that would change behavior is if someone set
            grid-template-row and -column we'd treat it as a massive
            grid. If you set one it wouldn't be a subgrid, but in
            the future it would be a 1 axis subgrid and you would
            get different behavior. dholbert thought it would be a
            dangerous upgrade path that we shouldn't try and do.

  jensimmons: Sounds good to me. I have a question, you said if I
              declare subgrid and then define grid-template-rows and
              areas I've turned my display into a grid?
  fantasai: That's what we considered. Right now it would ignore
            your declarations.
  jensimmons: As it's bad code.
  fantasai: It would be like you said col-width on a table.
  jensimmons: It sounds good to me. It makes sense to me.

  Rossen: Okay. Any other opinions?
  <tantek> this makes sense to me too. thanks TabAtkins fantasai for
           exploring this deeper.
  Rossen: I'm personally okay with that. It is a little hackier than
          I want, but given the restrictions it's the best we can
          come up with at the moment.

  Rossen: Do you want a resolution?
  TabAtkins: Yes.
  Rossen: Anyone objecting? Can you summarize?
  TabAtkins: The grid-template and grid-gap properties have no
             effect on a sub-grid.
  Rossen: If display property contains subgrid those are ignored.
  TabAtkins: Yes.
  Rossen: Okay, any objections?

  RESOLVED: The grid-template and grid-gap properties have no effect
            on a sub-grid

Auto-repeat inside grid-template shorthand
------------------------------------------

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0193.html
  <fantasai> https://drafts.csswg.org/css-grid/#explicit-grid-shorthand
  TabAtkins: We...the grid-template shorthand, one grammar was the
             full "let's draw ASCII" declaration. So you can draw
             with ASCII and on side and bottom declare lengths and
             widths. In one place it claims you can use repeat()
             which is an accident. All implementations allow repeat()
             for the rows as well. This is weird. The point of this
             is to give you a good visual representation of the grid.
             The grammar is set for 1 to 1 physical relationship.
  TabAtkins: Using repeat() in this breaks that. You don't have 1 to
             1 between a track and its size.
  TabAtkins: It doesn't make sense because the template has no
             intrinsic relation to the grid at the end.
  TabAtkins: So 1) auto-repeat should be invalid despite existing
             implementations. And remove the grammar that allows
             repeat() for columns as it was an accident.

  Rossen: Do we have a FF implementor working on this?
  * tantek would have to check with dholbert
  * tantek is not sure
  Rossen: Was this discussed with igalia?
  TabAtkins: We did with Manuel in the thread.
  dbaron: I'm on but don't know enough; ask dholbert or mats.
  Rossen: It would be great to gather opinions a little further.
  <fantasai> dholbert:
https://lists.w3.org/Archives/Public/www-style/2016May/0193.html ?
  Rossen: Basically, I'd like to get more implementor opinions. I'm
          fine with it on our side. I'm not sure if that's true for
          others.
  Rossen: If you're putting this on the table I'm assuming Blink is
          fine.
  TabAtkins: Yes. They'll be fine.
  fantasai: It's just a parsing issue.
  Rossen: So we can tentatively resolve and wait for dholbert or
          anyone else from webkit to comment and we'll go from there.
  TabAtkins: That would be good.

  Tentative resolution: auto-repeat should be invalid despite
      existing implementations. And remove the grammar that allows
      repeat() for columns as it was an accident.

  Rossen: We'll revisit next week and if there's no replies on the
          ML we'll call it resolved.

Heuristics issue
----------------

  <Rossen> https://drafts.csswg.org/css-grid/#algo-overview
  TabAtkins: I'm getting the spec being jumpy...it's 12.1
  TabAtkins: This is hard to explain. I'll go over and let people
             review.
  TabAtkins: When doing grid sizing the algorithm generally assumes
             everything is in the same writing mode. So inline size
             calculates first than block size. That's not always
             true, you sometimes have orthogonal flows. In those
             cases we have to give an estimate on the height area.
             Then, because the estimate was almost certainly wrong,
             we do a second pass using the updated info.
  TabAtkins: In theory this can keep happening until we stabilize,
             but the IE group said we can do this in 2 passes and we
             believe them so that's what we do.
  TabAtkins: The problem is the original estimate was quite bad. If
             any one row is a min-content or a flex or an auto we
             consider it to be infinite for the first run.
             Orthogonal flows can deal with infinite. But it's
             almost guaranteed wrong on the first pass.
  TabAtkins: fantasai realized we can do better in a lot of cases.
             If it only spans a min-content or max-content it will
             be at least that size. The proposal is to change the
             heuristic to take into account better estimates listed
             in issue 8.
  TabAtkins: This needs to be thought about in someone's leisure
             time. dholbert, fantasai, and I agree. This should
             always be at least as accurate and sometimes more. It
             should give us just as good or better layout and maybe
             remove the second pass.
  TabAtkins: No need to resolve today, but if someone outside of FF
             can review it would help.
  Rossen: My initial reaction was favorable. I'll send comments to
          the ML and we'll have a more definitive resolution. In the
          beginning when this was worked on for us treating those as
          undefined was the most straightforward, but there will be
          layout that would be unfavorable on the final result.
  Rossen: Let me digest and we'll comment back.
  TabAtkins: Thank you.

Error-handling preferences issue
--------------------------------

  <Rossen> https://drafts.csswg.org/css-grid/#issue-9191c5b6
  TabAtkins: It's issue 4 in the spec in section 8.
  TabAtkins: Item e.
  TabAtkins: The question is, subgrids do not have an implicit grid.
             They get the grid you tell them to have.
  TabAtkins: This is different from normal where you can position
             outside the declared columns and we'll add them.
  fantasai: We also create implicit tracks. subgrid won't grow to
            accommodate.
  TabAtkins: So how do we treat things when they try and go outside?
             Current spec is we use the clamping behavior. The other
             possibility is we consider this an error case and make
             it span the whole grid.
  TabAtkins: We don't have a strong opinion either way. Whatever the
             WG wants we'll keep in the spec.

  Rossen: Opinions? I don't have a strong one. spanning the entire
          grid would be obvious and somewhat weird. I don't recall
          anything similar.
  Rossen: Anyone have an opinion?
  Rossen: Or does TabAtkins 's proposal make sense?

  jensimmons: I want to have an opinion, but I don't think I
              understand what the difference would be yet.
  Rossen: TabAtkins can you give an example?
  TabAtkins: You've got a subgird that's 2 column and 2 row span.
             You have an item in the subgrid positioned in column 3,
             row 1.
  TabAtkins: Clamping proposal shifts its inward to row 1 column 2.
  TabAtkins: Span the whole subgrid makes it fill the 2 x 2 space.
  rachelandrew: Would the difference affect content flowed
                automatically?
  rachelandrew: I prefer the clamping thing.
  <gsnedders> I think I prefer the clamping thing too, FYI.
  <jensimmons> rachelandrew: \o/ So glad you are here.
  bradk: I prefer the clamping, it's more author friendly.
  Rossen: Sounds like people are inclined to have subtle hints.

  TabAtkins: So we can resolve on that?
  Rossen: Objections to resolving on clamping behavior for error
          cases on subgrid where items are outside the subgrid?

  RESOLVED: Take the clamping behavior for error cases on subgrid
            where items are outside the subgrid (issue 4)

  Rossen: I did want to say welcome Rachel
  <tantek> yes! welcome Rachel!
  <dauwhe> welcome Rachel!!

What level should break-spaces go to
====================================

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0134.html
  Florian: We resolved to add break-spaces value to overflow-wrap,
           but we didn't resolve if this was 3 or 4.
  Florian: I made the pull on level 3 because 4 is earlier in
           development. More important it was because some browsers
           do have the behavior and I'd like to add the switch so
           that they can keep the behavior. But if we're trying to
           lock down level 4 makes sense. koji thought 4, I thought
           3. What does the group think?
  Rossen: I'd prefer 4 given how long css-text 3 has been out there
          we should be locking down. Adding more things that will be
          moved sounds like a step backwards.
  fantasai: I don't think I have a strong opinion.
  * glazou totally agrees with Rossen
  Rossen: Do you feel this would slow level 3 down?
  fantasai: I doubt it. It's a pretty localized fix.
  fantasai: It's only adding a keyword and the definition. I could
            go either way.
  Florian: I think there's a limited chance to slow it. There's 1.5
           impl of the behavior. FF has it fully and Edge partly. So
           if we don't put it in L3 there's a risk the browsers will
           lose the behavior. If it's in L3 they'll have to add the
           other behavior, but won't have to remove what they have.
  Rossen: I doubt we'll lose anything in impl effort. As long as
          we're not slowing level 3 I'm fine with this going into it.
          Slowdown was my only reservation.
  <glazou> CSS 3 Text has been on the REC track since 1999...
  Rossen: To glazou point its been 17 years.

  Rossen: So any objections to adding this to level 3?
  Rossen: I'm looking to editors and people working on the draft.
  Florian: koji isn't on the call. I don't think he objected, he was
           just wondering.

  RESOLVED: Add overflow-wrap: break-spaces to level 3

Overflow
========

Clarify padding-bottom
----------------------

  <Rossen> https://github.com/w3c/csswg-drafts/issues/129
  TabAtkins: The question is, if you have a scroll container with
             overflow auto or scroll and it has padding on all
             sides, does the padding on the end edges get included
             in scrollable area.
  TabAtkins: The overflow spec says both. Implementations disagree.
             What should we go for?
  TabAtkins: I have some implementation on my blog that relies on
             Chrome letting you have it on the bottom.
  TabAtkins: This lets you do something like an overscroll.
  TabAtkins: But I don't know why browsers have gotten rid of the
             padding.
  Florian: To go further, if we have hanging punctuation that puts
           an overflow into the padding so I'd like to keep the
           inline padding.
  <myles> i think you can see it well at
          https://bug748518.bmoattachments.org/attachment.cgi?id=618078
  <fantasai> testcase
https://bug748518.bmoattachments.org/attachment.cgi?id=618078

  Rossen: Can you clarify, are we talking about...you have a box A
          that has overflow scroll
  Rossen: That box has fixed width and height and has adding 5em
  Rossen: Is it the padding of that box?
  TabAtkins: Yeah. If you have enough content to overflow all
             browsers but Chrome and webkit ignore block end. All
             ignore inline.
  Rossen: That's odd because it's on the box. If there's content
          that overflows, it's the content that overflows.
  dbaron: This is why browsers implement it that way. The spec is
          clear that the padding doesn't move when you overflow. The
          question is what is being scrolled by the scrollbar
  Rossen: Content. Not the box, the box is static.
  TabAtkins: The posision of the box doesn't change.
  Rossen: If you have an inset shadow when you scroll you don't
          suppose it will scroll.
  fantasai: No one is suggesting that.
  fantasai: Padding space is not visible.
  Rossen: Yes.
  Rossen: Unless you make it

  <gregwhitworth> testcase: http://jsbin.com/cujojereki/edit?html,css,output
  <Florian> Demo in the inline direction here: http://jsbin.com/tadiha

  fantasai: The backdrop of the box should be drawn as if it has no
            content. It shouldn't affect box decoration. Where are
            you positioning the content in respect to the edges of
            the scrollable area. In the top-left corner there's
            space left for the padding and that's part of the
            scrollable area. Then when you scroll to bottom-left
            it's not symmetric. The padding that's there is clipped.
  fantasai: You cannot scroll things such that it would sit if the
            padding existed.
  fantasai: It makes the scrollable area feel tight because there's
            no breathing space.
  <TabAtkins> It's weird as heck to argue that the padding space
              isn't scrolled; the scrollable box isn't shrunk inward
              by the amount of padding.

  Rossen: Let's go through the queue.
  dbaron: I'm okay with having something...assuming it's webcompat
          which it is not clear that it is...I'm okay with putting
          something in that produces the results authors expect. We
          should be clear its magic on a broken model. We're doing
          scrollable areas via overflow and that's not right. On the
          premise you do that padding is part of it.
  dbaron: I'm fine with adding a rule, but don't try and do it in a
          way that pretends it's anything other than a hack.
  TabAtkins: The reason people expect it is it doesn't feel like a
             hack.
  fantasai: He's saying that's not the spec model.
  fantasai: You can see this is the way it works. Suppose there's a
            box inside a scroller and the box is the size of the
            scroller. Suppose it overflows and you don't get a
            scroll because you can see it.
  TabAtkins: I strongly disagree and that's not chrome in the block
             axis.
  TabAtkins: If you have 100 box, 80 content and 50 padding you get
             a scroller. And that's intentional.
  <bradk> It's weird that the top of the content fits under the top
          padding, but the bottom of the content doesn't fit above
          the bottom padding.
  <gregwhitworth> I provided a block example above showing
                  Blink/Webkit behavior

  myles: Chrome and webkit have been shipping this block direction
         for years so it's web compat.
  dbaron: We don't know on inline.
  myles: That was mainly my point. That authors will expect the
         padding when you scroll down and it add symmetry that's
         powerful.
  Rossen: That would be a complete change in our model. I'm not sure
          we can commit.
  Rossen: I also want to echo the concern on web compat

  Florian: How does your model do things like ink overflow into your
           padding? Hanging punctuation is ink overflow.
  fantasai: That's an open issue
  Florian: Wasn't there other stuff?

  Rossen: We need to understand the compat issue. The box model is
          fairly well defined in CSS 2.1 and scrollbars were built
          on top. You can read the spec in both ways. I don't
          disagree on author expectation, but I would not resolve on
          a drastic behavior change without understand on what the
          web compat effect it.
  TabAtkins: dbaron was trying to say something on webcompat and he
             got covered.
  Rossen: If we go by that then we need to spec all kind of other
          quirks.
  TabAtkins: No. You asked what is webcompat and we have an argument
             this is.
  dbaron: I will not believe without proof that it's webcompat in
          inline.
  myles: It sounds like two issues, inline and block.

  tantek: I'm going to underscore what dbaron is saying. From having
          struggled with this we did reach a point of interop on the
          scrolling box padding behavior on desktop browsers. So I'd
          assume there are web compat issues on desktop. I'm not
          sure on mobile browsers and content. I would guess similar.
          Unless there's arguments from evidence I'm not buying it.
  myles: As I said, maybe we should discuss inline and block
         separately.
  Rossen: We don't usually for box model
  myles: One might be web compat, the other may not.

  <fantasai> tantek: load
https://bug748518.bmoattachments.org/attachment.cgi?id=618078 in
Chrome
  <fantasai> tantek: There's youre existence proof

  Florian: Small point, but even though I see that having the same
           for a long time tends to invite web compat, but I'm
           having a hard time seeing what would break.
  TabAtkins: Given that no one honors inline, the breaking example
             is where you have 100 px wide, 80 px content and 20px
             padding on both sides. You don't get a scrollbar today,
             but you will.
  dbaron: I'm worried about like you have random 100px scrollbars.
  tantek: Webdev have worked hard to avoid random scrollbars.

  TabAtkins: proposal: I would like to spec in the block axis
             padding is honored on both sides. Inline is not, but
             I'll put in an issue saying we'd like to make it
             consistent and input would be helpful.
  dbaron: Fine with me
  Florian: Okay with me, but having heard you example I think it
           would commonly break.
  TabAtkins: That's fine. That's why I said not honored and an issue
             saying let's try so someone can show how horrible it
             would be.
  TabAtkins: Does anyone object to that proposal?

  <Rossen> http://jsbin.com/qececaqilo/edit?html,css,output
  <myles> Rossen good example, that's helpful

  <gsnedders> avoiding scrollbars is frequently somewhere with
              browser sniffing, FWIW

  fantasai: So you must put block padding because Chrome does it.
  TabAtkins: It means all mobile and a good chunk of desktop is fine
             with it.
  fantasai: For inline we spec that you don't include the padding,
            but you may and we're trying to figure it out so please
            give us feedback. So a browser could ship with it.

  Rossen: I don't know if you've looked at the example I just pasted.
          What would be the expected behavior on that.
  [everyone looks]
  <tantek> Rossen, I'm seeing scrollbars in your example in both FF
           and Safari
  <tantek> I'm seeing interop between FF and Safari on Mac
  Rossen: This is what I was trying to explain. When you have
          content that outlines your padding box and content
          overflowing out of that.
  fantasai: The orange box is inside there and the padding box...okay
  fantasai: I think in that case my expectation is the padding of
            the scroller is effectively containing the geometry of
            the orange box.
  fantasai: What's overflowing is something we're unioning. If
            you're overflowing the box it's different than the
            padding.
  Florian: I'm super confused.
  Florian: Chrome is different than I expect.
  TabAtkins: The case Rossen posted would be no change, right?
  fantasai: Yes.
  TabAtkins: No geometry outside the orange box.
  myles: Rossen's case is different between browsers.
  fantasai: The bounds of the scrollable area would no change.
  TabAtkins: Outlines are crazy. Don't worry about those.
  Rossen: For this purpose you're not expecting to be adding more
          padding to this overflowing content from the inside box.
  TabAtkins: Yes.
  fantasai: They're not equivalent, but we don't expect change.

  <tantek> looks like we need more offline sharing of examples /
           assertions of interop
  <fantasai> tantek, we're at the end of the agenda. You can hang up
             if you want :)
  <tantek> fantasai, I don't expect it to get resolve on the telcon
           so hence suggesting a way for better understanding to
           continue

  <Florian> http://jsbin.com/digadoyohi/1/edit?html,css,output
  Florian: I just posted a new example. In the inline FF doesn't add
           padding back but Chrome does.
  [everyone looks again]
  Florian: The exact measure might depend on fonts.
  TabAtkins: I was testing this case.
  TabAtkins: I suspect I know.
  Florian: I don't.
  <myles> Florian's observation matches my own memory for how webkit
          behaves
  Rossen: Both FF and Edge have same behavior.
  Florian: Safari is with Chrome.
  Florian: Is Chrome doing the simple thing or is there a subtle
           corner case?
  <bradk> iPhone has padding to right of content.
  dbaron: FWIW I *think* there was a change in Gecko 5-7 years ago
          where we intentionally moved to match the spec.
  dbaron: The spec being 2.1.
  <fantasai> https://www.w3.org/TR/CSS21/visufx.html#overflow-clipping
  <fantasai> don't see anywhere that this is addressed...

  Rossen: Let's continue working on this. Based on the last 15
          minutes we've already shown a bunch of different behavior.
  <tantek> thank you Rossen
  Florian: Which means we might be able to change.
  Rossen: Let's continue working on this.
  Rossen: On the ML at the least...sorry, github
  Rossen: Add opinions to the issue
  <tantek> highly doubtful we can change
  dbaron: This might be one of those areas where it's hard to
          converge on a behavior because there's UA sniffing.
  Rossen: True, but in simple test cases we should have interop.
  dbaron: I'd hope we can, but it's possible we might not because
          this is older.
  <tantek> what dbaron said
  <gsnedders> I'd agree with dbaron if I had a mic
  Rossen: Fair enough.
  TabAtkins: Yeah
  fantasai: We should try
  Florian: Yeah, we should put an issue in the spec.
  Rossen: I'd agree we need to work on this. There's a bunch of
          things in overflow that are non-interop. Desktop web
          relies on one, mobile on another.
  Rossen: It's difficult to satisfy both.
  Rossen: For us this would be tricky because we have all the
          enterprise relying on all behavior.
  <TabAtkins> This is what I tested:
http://jsbin.com/vexahocayi/1/edit?html,css,output
  <TabAtkins> padding box overflows in both axises, but scrollbar only
shows up in block axis
  TabAtkins: At the least, I'll put an issue in the spec
  Rossen: Definitely!
  Rossen: This is worth pursuing.
  Rossen: It's a basic concept on how everything works

  <tantek> whatever comes out of testing, I'd be biased toward fewer
           scrollbars, and fewer "extra whitespace" scrolling (in
           mobile / touch etc.)
  <tantek> based on the fact that web devs try very hard to avoid
           annoying scrollbars showing up, right at the limits of
           what can be made to fit on a page

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

  Florian: Quick question...once the issue is in the spec can we do
           a WD?
  Rossen: Agreed. Can we have a new WD?
  <tantek> yes, new WD please
  TabAtkins: Yes. We e-mailed the current editor saying we simplified.
  Rossen: If there's no other things lets publish.
  <fantasai> https://drafts.csswg.org/css-overflow-3/
  Florian: In the private conversation we wanted to remove
           max-lines, the section on we don't know how to do
           overflow on print and media, the issue saying overflow-
           style used to exist
  <tantek> we don't have to worry about removing things before
           another WD. can always remove stuff later
  <tantek> just ship it
  <tantek> just publish, cut later
  fantasai: Let's just publish.

  RESOLVED: Publish a new WD for overflow

  <jensimmons> \o/
  <tantek> +1
  <fantasai> yay WD!
  Rossen: Thanks everyone. We'll talk next week.
Received on Wednesday, 25 May 2016 23:41:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 25 May 2016 23:41:41 UTC