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

[CSSWG] Minutes Telecon 2017-09-13 [css-flexbox] [css21] [css-inline] [css-values] [css-writing-modes] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Sep 2017 19:06:37 -0400
Message-ID: <CADhPm3sxrQyEyudaFtGZZsj+zj84p_eMFOuoUg-Vm+9UikpcCw@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.


  - RESOLVED: Take this edit
               as soon as dholbert gives approval.
  - RESOLVED: Publish an updated CR of Flexbox.

Meta bug for line height

  - Implementors were requested to review the tests and assertions
      Florian has compiled
      in order to work toward an interoperable line height.

Test for orthogonal flows in table cells

  - The use case Florian was testing for is a valid use case and the
      spec authors will need to edit the spec to clarify that it's

Radians considered useless without π

  - RESOLVED: Close issue #309 no change.

Font metrics calculation on elements which writing-mode doesn't
    apply to

  - RESOLVED: Add a clarifying note referencing cascade and then
              close issue #1782.

Reconsider the meaning of 1fr

  - Conversation will continue on github, though there was a slight
      preference expressed on the call to leave fr units as-is.


Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0026.html

  Rachel Andrew
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Anton Prowse
  Jen Simmons
  Alan Stearns
  Lea Verou

  François Remy
  Melanie Richards
  Geoffrey Sneddon
  Greg Whitworth

Scribe: dael

  astearns: I think we should start.
  astearns: First item, any extra things to add to the agenda?
  fantasai: Is grid issue from last week on? I don't have the agenda
  astearns: There is an issue on the meaning of fr unit.
  fantasai: That's the one.

Spec rec next steps

  astearns: Thanks Chris for run down on several items.
  astearns: I'm on the hook for V&U tests. Anyone else have an
            update to any item on the list?
  astearns: I will follow-up over email to make sure we have up to
            date ideas of where things are.
  <florian> the thing I said when nobody could hear is that UI is
            almost done: there are 2 (sets of) things that are still
            failing the test suite: cursor:auto, and svg with no
            fixed size as a cursor.


Intrinsic sizing with ∑flex < 1 is broken
  Github: https://github.com/w3c/csswg-drafts/issues/1735

  fantasai: There was an error in the algorithm for flexing for
            intrinsic size. We look at flexing algorithm in combo
            with min/max sizes so we give container enough space so
            when flexing algorithm takes place min/max are
            respected. The error was when flex values add up to less
            than one.
  fantasai: TabAtkins and I proposed fixes, we think are correct.
            We're happy to edit them in. If anyone wants to review,
            great. We're pretty confident.

  dbaron: Are implementors signed up to make these? Well, does
          change match existing impl?
  fantasai: Current implementations don't account for the flexing in
            calc of intrinsic. For grid we have impl that do that.
            This change is fixing a behavior that doesn't seem
            right. I think chrome is the one that does that...I
            don't remember other impl.
  dbaron: My worry is if somebody tries to impl do websites depend
          on old behavior?
  fantasai: There's 2 steps of impl. 1 is if you have the algorithm,
            tweak it. That would be to grid where I don't think we
            have any dependency. I think for sure we should fix
            that. For flexbox the algorithm overall isn't
            implemented so changing the algorithm won't affect
  fantasai: dholbert has volunteered to implement the algorithm, but
            he hasn't gotten to it.
  TabAtkins: They implement a simpler version of the algorithm and
             they are consistent in that, but it's wrong and
             dholbert is offering to fix that.
  fantasai: And that will make it more consistent with grid.
  dbaron: And if dholbert succeeds will other impl follow?
  TabAtkins: Yes, we will.
  <TabAtkins> (Re: compat, we implement an *almost* correct version
              of this for Grid already, the tweak to fix it only
              changes grids with a sum of fr < 1.)
  <TabAtkins> (Our Flexbox impl is currently the "simple and dumb"
              version, which matches what Firefox currently does for
              both Grid and Flexbox; if dholbert fixes in Gecko and
              it sticks, we're happy to change ours to match.)

  astearns: Has dholbert reviewed this proposed change?
  TabAtkins: We pinged him, he hasn't yet been able to do a full
  fantasai: It's not difficult to do, it's a tweak to some math.
            Largely it's a question of did we get the math right.
  astearns: I'd be okay with getting it edited in, but I'm a little
            concerned no one has checked the math. I'd be happier if
            someone looked and said yea or nay.
  fantasai: We can resolve and say it takes effect once verified.
  astearns: But that doesn't get us closer to publication.
  fantasai: It does b/c if we get replies today or tomorrow we can
            get it into pipeline.
  astearns: Does it make sense to publish even if this doesn't make
  fantasai: Yeah, there's a ton of changes. This is a CR so changes
            publishing takes 6 weeks. Might as well start.
  Chris: If it takes 6 weeks is dependent on how good DoC and
         changes are and availability of Ralph and plh.
  fantasai: DoC is compiled.

  astearns: Any other comments on resolving or resolve pending
  fantasai: I'd prefer to get resolutions in place b/c that will get
            things rolling.
  Chris: I agree.
  astearns: You propose to resolve we take this edit as soon as
            dholbert gives a thumbs up. Objections?

  RESOLVED: Take this edit as soon as dholbert gives approval.

Publication of Flexbox

  <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160526
  fantasai: Here's the DoC^
  fantasai: Two open issues. This one we resolved and another
            jensimmons and I found. We should fix that, but we
            should publish first since that one needs some thinking
            and discussion. I'd like to publish with this open and
            plan to fix in next round.
  Chris: That's fine. We can put that in the request. Issue 2 & 4
         don't have coloring. There was an objection on one issue in
         GH and astearns asked if it was formal. Is changes up to
  fantasai: I believe it is, I'll check.
  Chris: Okay, thanks. +1 to publication.
  astearns: Other opinions?
  fantasai: Changes is up to date.
  Chris: Great.
  astearns: Objections to publishing an updated CR of flexbox?

  RESOLVED: Publish an updated CR of flexbox.

  fantasai: I'll finish the edits.
  Chris: I'll start writing the transition.

Meta bug for line height
  Github: https://github.com/w3c/csswg-drafts/issues/1796#issuecomment-328713658

  astearns: I wanted to introduce this work because I think it needs
            more review. I'd like dbaron and others to look at this
            nest so we can have useful discussion and start
            resolving things to make line height more interoperable.
  florian: I think the result of my testing is we're more interop
           then I thought. Spec is wrong. I think there's 2 places
           we're not. One is how browsers fetch font metrics, there
           are differences and I didn't try and understand them.
  florian: One other exception is what happens with the first
           available font when the space character is excluded from
           unicode. We did resolve there recently, but I think we
           went a bit too fast. I made test cases for every
           assertion, so please go review. If you agree with me I'll
           make PR for the spec. If you don't I'll look.

  Chris: There's a commonly used trick where you use unicode to get
         a swash ampersand and rely on a second font after the swash
         first font.
  florian: I think your trick only works in chrome.
  Chris: Generally in FF too.
  florian: Please look at my test cases and tell me where it's
           wrong. In FF it goes with random stuff and speed of load
           changes what you get. I have a test case.
  Chris: Okay, I'll go review.
  florian: Please everyone go review and based on that we can have a
           spec that matches impl and impl that match each other.
  astearns: Anyone else have something on this topic?
  astearns: Thanks florian for doing this.

Test for orthogonal flows in table cells
  Test: https://github.com/w3c/web-platform-tests/pull/6969#issuecomment-328598209

  florian: Back at Tokyo I mentioned a few things with writing modes
           that weren't impl especially with orthogonal table flows.
  florian: The two things we have are if you set a max height on a
           table cell in a vertical writing mode within a horizontal
           writing mode table, is that supposed to work? I would
           assume so, but that's not reliable. I'm not good enough
           on tables to know if there's a spec that asks it to work.
  florian: Do people know if that is somewhere?
  astearns: fremy and gregwhitworth sent regrets.
  * fantasai considers that a Tables issue

  dbaron: We did discuss about...was it min or max prop on table
          cells in Paris? I think we decided it shouldn't do
  florian: That was min and I'm talking max. If you have a wrappable
           line should it wrap?
  dbaron: Yeah, the orthogonal thing makes it harder. There's a
          piece to ignore, but which.
  florian: If you have a long chunk of text in a table cell it's
           possible to make it wrap is my expectation. I do not know
           if there's a spec that agrees. I know we don't have
           interop. Only one wraps.
  fantasai: Your use case is totally valid and useful, so if we can
            we should make that work.
  <fantasai> florian, is the first one filed as an issue? So I would
             file it as an issue against tables and say "This should

  florian: Other one is something I haven't written...
  florian: This is when you start setting the height on the table
           itself and see if that does anything.
  <florian> https://wptest.center/#/json:{%22title%22:%22UntitledTest%22,%22html%22:%22%3Ctable%3E%3Ctd%3Exx%20xx%3C/td%3E%3C/table%3E%22,%22css%22:%22table%20{\r\n\theight:%20100px;\r\n\tborder-spacing:%200;\r\n}\r\n\r\ntd%20{\r\n\tpadding:%200;\r\n\tfont:%2050px%20/%2050px%20ahem;\r\n\tcolor:%20green;\r\n\twriting-mode:%20vertical-rl;\r\n\tbackground:%20red;\r\n}%22,%22jsBody%22:%22%22,%22jsHead%22:%22%22,%22watches%22:[],%22watchValues%22:[]}
  florian: second test case ^
  florian: This too behaves differently in edge and ff.

  florian: If no one has table specs loaded in their brains we
           shouldn't solve here. There is lack of interop, there is
           a preferable behavior, so we should try and make that
           possible and see if there's a spec that says it.
  florian: I can write a spec test, but I don't know the specs well
           enough to know if it's there.
  astearns: Since fremy isn't on I think we should action him.
  florian: He raised this and said he didn't know.
  fantasai: Writing modes spec says rules for layout are analogous,
            but I don't know what the rules for layout are. It does
            mean the analogy needs to be taken into account.
  florian: I don't know if analogy is sufficient. In the table
           layout algorithm where it says what's into account or is
           it logical/physical width and height...I don't think
           that's all clear.
  florian: I don't think writing mode is clear enough to define on
           css table or 2.1 not written with that in mind. There's
           the terminology for it.
  astearns: Sounds like fantasai says it's not defined in writing
            modes and it's probably not in tables
  <fantasai> https://drafts.csswg.org/css-writing-modes-3/#orthogonal-flows
  fantasai: Writing modes says [reads] parent controls positioning,
            but child controls sizing, what width and height means.
            Tables are more complicated an may need diff set of rules
  florian: Yeah, it's something in tables about to determine table
           width you get width of every cell.
  fantasai: That was probably fine when we said do magic in 2.1, but
            looking at grid may help us figure out tables 3.
  astearns: This is part of what we're doing table spec is to find
            this not interop and defining something.
  astearns: I do think it's on fremy and gregwhitworth to figure out
            what table spec should say.
  florian: I'll ask for permission to remove my current pull and
           make a new one with this.
  astearns: Thanks for test cases.

Radians considered useless without π
  github: https://github.com/w3c/csswg-drafts/issues/309

  astearns: Looks like we want approval to close no change.
  fantasai: Basically the argument is you need pi to use radians,
            but we have turns to you can divide by 2 and use turns.
  <fantasai> turns = TaURadiaNS
  Chris: +1 for closing. I think it's very clear.
  Chris: The reason we have radians is people can spit it straight
         out without converting to degrees first.
  astearns: And that there is no impl that wants to add makes me
            think we should close.
  <florian> +1
  astearns: Obj to closing no change?

  RESOLVED: Close issue #309 no change.

Font metrics calculation on elements which writing-mode doesn't
    apply to
  github: https://github.com/w3c/csswg-drafts/issues/1782#issuecomment-328222293

  astearns: There's a proposed change and I think dbaron had a
            comment this might be covered?
  fantasai: Possible.
  dbaron: There is text in 2.1 saying applies to doesn't effect
          computed unless it explicitly says it does.
  fantasai: That's fair. Do we need to clarify in spec?
  dbaron: Possibly. That also feels like it should be in L3.
  fantasai: There isn't a L3 of that chapter.
  dbaron: It's in definition of computed value which I think would
          be cascade. I didn't really look at that.
  dbaron: Actually, it's in. I think it's okay.

  fantasai: You recommend close no change?
  dbaron: I think so unless someone sees something else?
  astearns: Would a note make sense?
  astearns: For impl clarity?
  fantasai: I can change the proposed text into a note and reference
  astearns: Objections to add a note?
  dbaron: sgtm
  fantasai: If there's a suggestion on section, we can figure that
            out. I might stick it in module interactions.
  astearns: Sounds alright.

  RESOLVED: Add a clarifying note referencing cascade and then close
            issue #1782.

Reconsider the meaning of 1fr
  github: https://github.com/w3c/csswg-drafts/issues/1777

  fantasai: There were good comments. I need to dig through those.
            So, thanks for commenting.
  astearns: Does anyone have an opinion that has not commented on
  TabAtkins: I haven't dug deep. I need to spend time thinking about
  * tantek also needs more time to understand implications
  <tantek> Without having looked into it deeply, I would tend to go
           with with Rachelandrew's analysis
  jensimmons: I'd like to have an opinion, but I feel like I need
              examples to understand impl and I haven't done that.

  fantasai: Right now, as overview, min size of a grid container can
            take starts with min track sizing and if there's extra
            space the tracks will expand until reach max. Right now
            fr has an impl min of auto which by default is the min
            content, but if they have min width or height it uses
            that. Max track is the flex unit.
  fantasai: Same is true in height. Proposal is instead of using min
            for fr, we use 0 so content will overflow track if it
            can't shrink to 0
  TabAtkins: Reason for current is it matches with flexbox. If you
             say flex 1 you start with min-width of auto. This works
             the same way unless you override.
  fantasai: Where this becomes confusing is when they use track
            sizing for a large amt of content which they expect to
            get clipped or shrink and we're enforcing a min on that
  TabAtkins: I feel it's a lot like the confusing part of flexbox
             where the min of height is the auto and that's
             something larger then intended.
  TabAtkins: It's the blow up in a good way where you don't lose
             anything, but it's unexpected.
  TabAtkins: This is exactly us porting the flexbox behavior.
  fantasai: That's the background. We can all look more deeply and
            discuss on GH.
  astearns: Thanks to rachelandrew and fremy for already commenting

  astearns: Anything else on this?
  jensimmons: Thanks for the info, that makes it clear. My first
              take is I hesitate to do this b/c the way fr works
              right now is incredibly useful. I can see the want,
              but I don't know if it's right. We'd break stuff if we
              do this, but the way it's written is also the most
              useful way to use fr.
  jensimmons: I think education may be right instead of a change.
  astearns: Thanks jensimmons. Sounds like we should have a few more
            examples in the issue going through impl of actual
            email. I think we should take this to GH and come back
            in a week or two.
  astearns: I believe that's it for the agenda.

  astearns: Reminder TPAC is coming. Register before Oct 7 to get
            the lower price. Anything else for the agenda this week?
  astearns: Everyone gets 15 minutes back!
Received on Wednesday, 13 September 2017 23:07:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:08 UTC