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

# Dael Jackson (a day ago)

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread

with an appropriate subject line.

Flexbox

Meta bug for line height

  • Implementors were requested to review the tests and assertions Florian has compiled (w3c/csswg-drafts#1796 ) 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 possible.

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.

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

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

Present: 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

Regrets: 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? [silence] fantasai: Is grid issue from last week on? I don't have the agenda up. 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.

Flexbox

Intrinsic sizing with ∑flex < 1 is broken

Github: w3c/csswg-drafts#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 implementations. 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 review. 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 it? 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 dholbert? 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> 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 date? 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.

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

Meta bug for line height

Github: w3c/csswg-drafts#1796

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: w3c/web-platform-tests#6969

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? [silence] 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
      something.
    

    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
         work"
    

    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> 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> 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: w3c/csswg-drafts#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: w3c/csswg-drafts#1782

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 cascade. 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: w3c/csswg-drafts#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 github? TabAtkins: I haven't dug deep. I need to spend time thinking about it.

  • 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
        content.
    

    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

        there.
    

    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!

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.