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

[CSSWG] Minutes Telecon 2018-05-02 [css-grid-2] [css-grid-1] [css-overflow] [css-scroll-snap] [css2] [css21] [css-fonts]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 2 May 2018 21:39:08 -0400
Message-ID: <CADhPm3u5dF+THoDNQRw-VXyWAvZ1wmwFC5Z31uqhT-fJzVoPeQ@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.

CSS Grid L2

  - RESOLVED: Subgrid line names are additive to the parent grid's
              line name. (Issue #2622)
  - RESOLVED: Add this proposal ('auto <custom-ident>' to mean the
              same as 'auto' except the line it resolves to has to be
              named '<custom-ident>'.) to grid L2. (Issue #796)

CSS Grid L1

  - RESOLVED: Grid items spanning fr tracks do contribute to fr track
              minimums for intrinsic sizes with the addition that fr
              tracks not 1 to 1 ratio get contributed to based on that
              ratio. (Issue #2177)
  - RESOLVED: Take option B (contribute 0 and resolve as percentage
              for column and row gaps).


  - RESOLVED: Ignore anonymous boxes in this case
              (text-overflow:ellipsis). (Issue #2595)

Scroll Snap

  - RESOLVED: Have the default scrolling behavior for nested scrollers
              to have scroll snap. (Issue #2593)


  - All permanent links should point to /tr/css2 which points at CSS2.1
  - RESOLVED: Say we want it [CSS 2.1] to be the same shortname and
              that auto obsoletes the older

CSS Fonts

  - TabAtkins proposed that for the fontface rule if a URL has a
      fragment identifier you don't know how to deal with you treat it
      as invalid (Issue #2566)
  - Myles felt that there may be better ways to handle some unknown
      fragment identifiers so conversation will continue in github.


Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0000.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Garrett Berg
  Elika Etemad
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Liam Quin
  Manuel Rego
  Melanie Richards
  Florian Rivoal
  Geoffrey Sneddon
  Eric Willigers

  Rachel Andrew
  Angelo Cano
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Chris Lilley
  Alan Stearns
  Lea Verou
  Greg Whitworth

Scribe: dael

CSS Grid 2

Subgrid local line names
  github: https://github.com/w3c/csswg-drafts/issues/2622

  fantasai: Basically we're able to give the subgrid some line names.
            Should they hide the parent names or be in addition?
            Originally had in addition, but wanted to check what
            people prefer.
  Rossen: My question is what is the multiplicity? If we have n levels
          of subgrid do we need n levels of name?
  fantasai: Yes.
  Rossen: That's the down side
  fantasai: It's just a set, though. No prioritization. You're just
            adding names to the set.

  Rossen: What is current matching? If there's a grid that defines
          line as foo and the subgrid defines it as bar do I have to
          call it foo bar?
  fantasai: Either foo or bar would work. Just like if you gave it
            multiple names in the beginning. We're just combining the
            sets here from different levels.
  <TabAtkins> `[foo bar]` already gives a line two names
  Rossen: Sounds fine

  Rossen: Other opinions or objections? Proposal is to keep combining.
  <rego> JFTR, sounds good to me too
  Rossen: Not hearing objections

  RESOLVED: Subgrid line names are additive to the parent grid's line

CSS Grid 1

Grid track sizing items spanning a flexible track
  github: https://github.com/w3c/csswg-drafts/issues/2177

  fantasai: This was a case where when Microsoft designed their
            algorithm if you had an item that spanned an auto track
            and a flexible track the space required to fit the item
            would go into the flexible track. This is frequently used
            in design where the auto track is tight to the content
            only in it.
  fantasai: We inherited this in algorithm. When you shrinkwrap the
            grid we don't have a point at which we consider the size
            of the spanning item. Flexible track goes to 0 and the
            other track doesn't expand so it overflows.
  TabAtkins: Manuel's picture in the first message shows the problem.
             #1, 2, and 3 the grid expands to the full width of the
             item. But in the 2fr columns they don't. Section 5 is the
             problem. 1 auto and 1 fr. A single auto or 2 autos expand
             correctly, but because the interaction of auto and fr you
             don't get the good behavior.
  fantasai: Rossen explained high level how to incorporate this into
            the algorithm. TabAtkins and I tried to do that, but we
            realized you might have multiple fr tracks or a different
            ratio. We added a new section and changed how space is
            distributed to try and keep the ratio as far as we can.
            There are conflicting requirements like try and shrink as
            small as you can. You don't always have tightest or ideal
            flex, but you get close.
  fantasai: We'd like WG review on if this is the right way or if
            there's other ideas on how to do this.

  Rossen: What you described for multiple fr tracks with a different
          ratio than 1 to 1 your proposal is reasonable and what I'd
          expect. From that PoV I'm fine with the proposal. I haven't
          done a full review, but I won't block because I trust you
          did the changes you outlined and it sounds good to me.
  Rossen: Is this agenda+ to elevate awareness or do you want to
  fantasai: If everyone who wants to look has let's resolve but if
            anyone wants time to review that's fine.
  Rossen: Does anyone want more time to review? I personally don't.
  Rossen: Then can we resolve on the current proposal? Grid items
          spanning fr tracks do contribute to fr resolution for
          intrinsic sizes with the addition that fr tracks not 1 to 1
          ratio get contributed to based on that ratio.
  Rossen: fantasai if you've got better wording?
  fantasai: looks good to me.
  Rossen: Opinions or objections?

  RESOLVED: Grid items spanning fr tracks do contribute to fr track
            minimums for intrinsic sizes with the addition that fr
            tracks not 1 to 1 ratio get contributed to based on that

Percentages gaps and intrinsic size
  github: https://github.com/w3c/csswg-drafts/issues/509

  <rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-381759138
  rego: I reopened it.
  rego: All browsers now support percentage in column gap in multi
  rego: All of them are interoperable. But they're not following new
        text in spec. Chrome and webkit we don't see an easy way to
        follow for width so I suggest we change the text to says
        something like % resolves to 0 when resolved against the base
        size. Something like the indefinite size is what we should say
        because the logical width is not indefinite.
  rego: That causes overflow in some cases but I don't think there's a
        way to do it better and changing spec text would make it match

  <fantasai> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-356256873
    B = contribute zero, resolve as percent
    D = contribute zero, resolve as zero
    F = contribute zero, resolve as percent (for column-gap) or zero
        (for row-gap)
  fantasai: If we go back to the options before there was option d
            which was contribute 0 resolve as 0. Igalia is saying we
            don't know when to resolve if it's at 0 or not because
            information on whether the current size of the container
            was a content-based size isn't part of what's given to
            grid when it's doing layout.
  fantasai: It's easier for impl if they continue tracking just the
            information they have already, i.e. the size of the
            container and therefore the percent resolves.
  Rossen: I can't speak to other impl, in our grid impl we know if
          we're doing layout for sizing and measuring the content vs
          sizing when we're not shrink to fit. From that PoV I don't
          think we have anything in the spec that prevents a impl from
          passing this info
  Rossen: Looking at current interop around this....based on the
          codepen from the issue seemed like we all agree on behavior
          of grid.
  Rossen: rego what I hear is once we go down...if we change
          resolution from b to d, contribute 0 resolve as 0, we
          minimize amount of potential overflow, but also drop ability
          to have percentage column gaps. Last time we discussed the
          one constant feedback from webdev was they don't want to
          drop the gap. It's more intuitive if you see overflow and go
          and fix it rather then add values and have no effect.
  Rossen: I'm not sure we're driving toward an ergonomic solution.
  fantasai: Previous resolution was b and we're proposing switch to d.
  Rossen: In that case I agree and misunderstood the proposal.

  rego: It would be more like f.
  rego: It would be like when grid resolves percent for width and
        height in regular blocks they're different so same here.
  Rossen: Okay, I'm with you.
  Rossen: Other opinions on this?
  fantasai: Proposal is to resolve the percent in column gaps but not
            row gaps?
  rego: Yes. To resolve the percent when the size is definite, but not
        when indefinite. Width is only indefinite for intrinsic sizes.
  fantasai: That gets to the point where we wanted symmetry and we
            don't have that.
  Rossen: Same concern as fantasai. Only thing that is symmetric is
          we're talking definite vs indefinite instead of width and
          height. I wasn't going to object hard, but I'm with fantasai
          that we want to keep as symmetric as possible. Just because
          of how flow layout works today more often then not width
          will be definite and height indefinite or vice versa.

  rego: There is the other issue about how percentage tracks work
        where they should be symmetric and resolve always. So maybe
        that's an option here. But no one is supporting the heights
        for percentage rows yet. Maybe that's the way to go.
  Rossen: This is option f?
  rego: Option b I guess.
  <rego> https://github.com/w3c/csswg-drafts/issues/1921
  rego: Following what we resolved in issue #1921. It's not
        implemented, but we resolved that way in the past.
  Rossen: Going through 1921 resolution it makes sense, but
          implementations have to catch up. Once we do we'll have
          symmetric behavior. Then we need to do same thing for gaps.
          That would be behavior b.
  rego: For multi column it's what we're doing right now. We're always
        resolving the percent because multicol only has column gap.
  Rossen: Right but for grid it's both column and row.

  dbaron: I'm not an expert on grid, but I felt like I liked the
          original proposal from rego a bit more. There's a lot of
          stuff where width and height just doesn't work the same way.
          Things that happen in intrinsic width pass shouldn't effect
          layout pass.
  Rossen: I wouldn't disagree in general, but I would slightly
          disagree in the case of grid because we've been trying for
          as symmetric as possible. We had a fully symmetric
          implementation and that fell through. It will require more
          passes to make symmetry stable, but it's possible.

  Rossen: Let's try and move forward.
  Rossen: Proposal in the issue was we resolve to have a contribute 0
          and resolve as percentage
  Rossen: Correct?
  rego: That's not what's in the issue, but yeah. That's the new
        proposal to keep symmetric behavior following the tracks
  Rossen: Which is option B.
  Rossen: Any opinions or objections?

  RESOLVED: Take option B (contribute 0 and resolve as percentage for
            column and row gaps).

CSS Grid 2

Auto-placement aligning to a named line
  github: https://github.com/w3c/csswg-drafts/issues/796

  Rossen: RachelAndrew raised this, but she's not on. fantasai can you
  fantasai: There have been several requests to do auto placement but
            filter out lines that don't match a name. Right now auto
            placement uses auto keyword. Add a custom ident for the
            name after the auto. So auto and the name would only do
            placement on lines with that name.
  fantasai: This is level 2 of grid.

  Rossen: Seems reasonable. I'm trying to understand primary use case
  fantasai: Example is wanting to have narrow and wide columns, some
            items should go in narrow and some in the wide. You name
            the lines to make the distinction and then be able to
            filter out the ones that match what you're looking for.
  Rossen: Okay. What's behavior if I list all named lines?
  fantasai: Proposal is you only have one custom ident. A line can
            have many names so if it matches any name it matches.
            That's the same as looking for lines. If you wanted
            various behaviors you'd name the lines differently.
  TabAtkins: Identical to if you spec a line name right now. It's just
             giving you auto placement with same behavior.

  Rossen: Sounds reasonable. What do others think?
  florian: I like it
  rego: Level 2?
  Rossen: Yeah.

  rego: Another commonly requested feature is spanning until last line
        including implicit grid?
  fantasai: There's another open issue on that. We don't have a
            solution to please comment there.

  Rossen: Objections to accepting proposal to add to L2?

  RESOLVED: Add this proposal ('auto <custom-ident>' to mean the same
            as 'auto' except the line it resolves to has to be named
            '<custom-ident>'.) to grid L2.


text-overflow and anonymous blocks
  github: https://github.com/w3c/csswg-drafts/issues/2595

  florian: Text-overflow: ellipsis works on block containers. It is
           not inherited so if you have nested blocks and inner ones
           overflow the ellipsis doesn't appear. It has been that way
           forever. New issue is if the element you apply the
           text-overflow: ellipsis to has the text directly as a child
           it gets wrapped in an anonymous block. Should it display
           the ellipsis there is different between browsers and
           ambiguous in the spec.
  florian: Spec arguably says no, but that's not ideal. Edge disagrees
           but fremy says Edge is changing as well. I don't know if we
           need a change or a clarification but we should say
           anonymous boxes are ignored for this purpose.

  Rossen: Besides wordsmithing, I'm okay with such a resolution. Other
  Rossen: Is this acceptable?
  fantasai: I'm in favor of ignoring anonymous boxes here.
  Rossen: Objections?

  RESOLVED: Ignore anonymous boxes in this case

Scroll Snap

Multiple nested scrollers and a "default" scrollIntoView()?
  github: https://github.com/w3c/csswg-drafts/issues/2593

  TabAtkins: I suspect it's resolved at this point, but making sure.
             majidvp and our other implementors that are getting our
             scroll snap up to date with the spec found an
             interaction. Spec defines an interaction between scroll
             methods alignment and scroll snap. You try to align via
             how the scroll method says and if you need to snap after
             you do.
  TabAtkins: Nested scrollers when you have to go multiple deep to get
             the element in view: Conclusion is you first align all
             the scrollers as you go down according to scroll method
             alignment. If any scrollers have scroll snap you honor
             that to bring them into alignment. And that's about it.
  TabAtkins: Unless anyone disagrees that's what we concluded in the
             thread which means no edits to the spec except we might
             want to clarify the wording.
  Rossen: Sounds reasonable. Any other opinions or objections?
  Proposal: Have the default scrolling behavior for nested scrollers
            to have scroll snap
  TabAtkins: Yeah, sure.

  RESOLVED: Have the default scrolling behavior for nested scrollers
            to have scroll snap.


Declare CSS2 as superseded
  github: https://github.com/w3c/csswg-drafts/issues/2589

  fantasai: Proposal was to declare css 2 as superseded. However as it
            stands now it's the css 2.1 spec. What we did is at the
            end of the css2.1 cycle we thought having css 2 around was
            bad and we merged the shortnames in. We've done that for
            other specs before. So I don't think we can declare css2
            superseded because we're using that short name for 2.1
  fantasai: There were resolutions to make sure that various shortcuts
            point to the right version. We need to make sure they're
            impl. tr/rec/css2 points to old. We need webrec to move
            that alias to point to same as tr/css2
  fantasai: Old css2 publication should show the I'm out of date
            notifications. But it's an older date of same spec so not
  florian: I agree most important is redirect. That said it's not
           short names that are superseded, it's rec. We could call
           the 1998 rec superseded. I'm not sure what that gets us.

  fantasai: Question. I have a rec about something like css
            namespaces. Then we see an error, go to cr, and then go to
            rec. Do we have to make the old rec superseded?
  florian: Process doesn't take into account levels.
  fantasai: Not relevant.
  gsnedders: I think significant thing in 2.1 was there is a change in
             feature set. I think we added features to 2.1 so it's a
             different document as defined by the process. It's the
             presence of new features that's significant.

  gsnedders: My view here is we should makes sure we have the right
             base data and I don't care how we achieve that. If the
             process makes no sense for what we do that's a bug in the
  dbaron: I'm not sure how well thought through the process is. I
          think superseded came about because there were people that
          wanted to make it as obsolete because there were new
          versions but they didn't want to call it obsolete. This was
          we don't want to mark the short name as the same thing. I'm
          inclined to think we should come up with what we think
          process should be. And I think we should make sure short
          names redirect, not mark as superseded.
  gsnedders: And that we get the correct this is out of date notice.
  florian: I think we need to do that and fix the short name first.
           Then we should get process fixed to say any newer rec of
           the same name supersedes previous.
  gsnedders: CSS 2 and 2.1 are in a slightly odd state because most
             things under the same short name don't both appear in
             tr.rdf. There's a bunch of things to fix around this.

  florian: From the csswg pov we just need to say we want CSS2.0 and
           2.1 to be the same shortname (CSS), and that newer RECs of
           the same shortname supersede the old ones, and the rest is
           just tooling bugs.
  Rossen: I like that summary. Do others agree?
  Rossen: Objections to say we want it (css2.1) to be the same
          shortname and that auto obsoletes the older?

  RESOLVED: Say we want it (css2.1) to be the same shortname and that
            auto obsoletes the older

  gsnedders: What should tr/css21 to point to once 2.2 is published?
  florian: Permanent redirect?
  fantasai: Or call it 2.1 forever.
  florian: That's also okay.
  gsnedders: But no one wants it to point to 2.1.
  florian: Sure.

Values & Units

Define which subresources block the DOM load event
  github: https://github.com/w3c/csswg-drafts/issues/1088

  TabAtkins: fantasai requested to figure out what spec it goes in
  Rossen: whatwg?
  gsnedders: We resolved in values and units.
  TabAtkins: [reads]Add proposed dom events to Values & Units. Okay.

  fantasai: Yes. Anne added the agenda+ I don't know why.
  Rossen: I'm okay to move on. We can come back if there's a need to

  dbaron: I think there's stuff to discuss here.
  Rossen: What would you like to discuss or does it stay in GH?
  dbaron: GH may be fine. There's a bunch of non-interop but we have
          space to converge if we agree to try and progress in that
          direction. Example @import blocks if it's one level deep,
          but not further and other browsers never block. I think we
          should be consistent and not having different behavior at
          different depths.
  dbaron: But we can discuss more on issue.
  Rossen: I think that's better.

  <gsnedders> I think Anne added it because Domenic drafted some text
              in HTML to better define what blocks the load event,
              including CSS.
  <gsnedders> and Domenic said "it would be great if the CSSWG was
              able to resolve this one way or another, write the
              tests, and move the definition into one of their specs"

CSS Fonts

Unknown fragment identifiers in @font-face src
  github: https://github.com/w3c/csswg-drafts/issues/2566

  TabAtkins: Some @font-face formats let you do special things with
             fragments. There might be more in the future. Question is
             how should we handle font URLs in @font-face with unknown
             types of fragment identifiers.
  TabAtkins: Initial suggestion was ignore, but I suggested do same as
             image function where if you see a fragment ID and don't
             know how to handle treat the URL as invalid. You don't
             know what the fragment is trying to do.
  TabAtkins: Suggestion: we spec that for the @font-face rule if a URL
             has a fragment identifier you don't know how to deal with
             you treat it as invalid.

  myles: Not sure I agree. It seems in some situations you want to
         treat fragment as unknown and some others for whole is
  <myles> my client crashed
  TabAtkins: Example. Browser that doesn't know what an open type
             collection is. Your fragment says load the second.
             Browser tries to download but you don't know what will
             happen. Best situation is it sees a url that says to do
             something it doesn't understand...best thing to do is to
             say I don't know what to do, skip it.
  TabAtkins: I don't think doing something arbitrary can be argued as
             better for the user.
  fantasai: Treating uninterpretable fragment IDs as invalid seems
            appropriate. It's just like if you got a URL with a scheme
            you can't load you treat as invalid.
  myles: TabAtkins said browsers that don't understand collections
         will ignore the whole thing, but I think all 4 browsers do
         understand collections
  TabAtkins: Yes, it was a hypothetical example. I was using it as a
             stand in for a future where the fragment does something
             significant and you either load it and do something wrong
             or load it and have no idea how to deal with it so you
             wasted bandwidth.

  myles: It sounds like there is a real discussion so we should maybe
         continue next week.
  TabAtkins: I'm repeating from the thread so put your arguments in
  Rossen: Sounds like we won't get to consensus today. We'll take it
          up next week.

  Rossen: Thank you for calling in. Have a great rest of the day/night/
          whatever your timezone is. We'll chat next week.
Received on Thursday, 3 May 2018 01:40:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 May 2018 01:40:08 UTC