W3C home > Mailing lists > Public > www-style@w3.org > November 2019

[CSSWG] Minutes Telecon 2019-11-13 [css-text-4] [css-fonts-4] [css-grid-2] [css-values-4] [css-grid-2]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Nov 2019 18:29:14 -0500
Message-ID: <CADhPm3uE=MgSW+8y5ExpjB1+9KFs86eWju8TgjN+X1JCWAxS3A@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 Text L4

  - RESOLVED: Publish new WD for Text 4

CSS Fonts L4

  - RESOLVED: Republish Fonts 4

Grid L2

  - RESOLVED: Pick option 2; effectively subset the grid area into the
              subgrid (Issue #4411: Subsetting grid-template-areas in
  - RESOLVED: Start L3 with all work that is in L2 but not about
  - RESOLVED: Publish Grid L2 as CR

CSS Values 4

  - The group was interested in seeing specific details for changing
      attr() to be more var()-like (Issue #4482: Switch advanced
      attr() to being var()-like) so TabAtkins will write up spec text
      for review.

CSS Grid 1

  - RESOLVED: Give the 2nd option a chance and see if there are compat
              reasons to instead keep current behavior (Issue #4475:
              Resolved values of grid-template-rows/columns don't
  - TabAtkins will look into what the Gecko and Chromium devtools
      expose about grid to see if something similar can be specified
      as a future enhancement.
  - RESOLVED: Specify serialization as proposed in
              [When serializing either the specified or computed value
              of a <<string>> value of 'grid-template-areas', each
              null cell token is serialized as a single "." (U+002E
              FULL STOP), and consecutive cell tokens are separated by
              a single space (U+0020 SPACE), with all other white
              space elided.]


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0005.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser (IRC only)
  Dael Jackson
  Chris Lilley
  Peter Linss
  Theresa O'Connor
  Manuel Rego Casasnovas
  Florian Rivoal
  Christopher Schmitt
  Jen Simmons
  Alan Stearns

Scribe: dael

  Rossen: It's 2 minutes past, let's start
  Rossen: Wanted to call if there are extra agenda items or items to
  fantasai: Brief announcement
  <fantasai> https://www.w3.org/wiki/Process2020
  fantasai: We posted an explainer to process changes and edits at
            this wiki^
  <fantasai> https://lists.w3.org/Archives/Public/spec-prod/2019OctDec/0007.html
  fantasai: If you have comments on improving, like the changes,
            dislike the changes, let me know about problems. If you
            have opinions forward them to spec-prod

  <tantek> quick summary, Process2020 explainer is looking quite good.
           Only nit is I don't think the Registries piece is mature
           enough as compared to the rest. I'd advise splitting that
           out and giving it more time to iterate/develop, perhaps for
  <tantek> everything else I'm looking forward to reviewing closely
           (actual process doc changes), and quite optimistic about. :)

  astearns: TabAtkins wanted first item to be postponed slightly on IRC
  Rossen: I see Chris will be a bit late for fonts 3
  astearns: TabAtkins will be at least 15 minutes late


  Rossen: Text level 3
  florian: Text 4; fonts 3
  fantasai: fonts 4 as well; fonts 3 is REC isn't it?
  Rossen: It is.
  Rossen: Let's do text L4

Text Level 4

  Rossen: Is it editorial?
  florian: Not only. At previous F2F we discussed word boundary in
           spaces, the text was added. It was announced and review
           requested. We're not getting to CR, but it's been in the ED
           for a while and it should go into an official space
  florian: It's been a year since it was published. Sounds like good
  Rossen: And the edits are in?
  florian: They are. It's the things I talked about at last F2F. Maybe
           some editorial tweaks
  Rossen: Great.

  RESOLVED: Publish new WD for Text 4

Fonts Level 4

  Rossen: Fonts 4 should we wait for Chris?
  fantasai: Chris is on IRC
  <ChrisL> Please wait until later
  fantasai: I think we publish since he requested
  <ChrisL> Ok great

  RESOLVED: Republish Fonts 4

Grid L2

Subsetting grid-template-areas in subgrids
  github: https://github.com/w3c/csswg-drafts/issues/4411

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-548945615
  fantasai: Summary comment^
  fantasai: Two proposals, make grid-template-areas a thing and
            exclude names from inheriting. Currently grid-templates
            make start and end and those would not inherit into subgrid
  fantasai: Other option is we take those names and instead of saying
            don't inherit in, they do inherit in and if there's
            partial overlap we clip start or end so they exist in the
            grid and you can position to the overlap
  fantasai: Slight inconsistencies for both. If we exclude then a
            manually created grid area such as named lines as
            foo-start I implicitly create foo which I can position
            into. Kinda works on a subgrid; if both lines overlap.
            True in both cases
  fantasai: Question is do we want...we didn't want to create
            inconsistent behavior for templates. Want to say either
            set to part it overlaps or exclude all lines. Those are
            the two options.
  fantasai: Would like to hear from other preference
  <fantasai> A) Exclude parent template and its implicit line names
             from subgrid
  <fantasai> B) Subset parent template to the part where it overlaps
             the subgrid, allowing it to be usable

  Rossen: Prefer second option.
  Rossen: Having the grid-template-area lines not available from
          subgrid is quite weird given that rows and columns are
  Rossen: I would lean toward the second solution if we have to pick
          from these two
  dbaron: Looks like Mats preference was first, but seems reasonably
          okay with either. Seems he had impl of 2nd and changed to
  fantasai: He originally wanted B, then did A when we weren't sure
  Rossen: dbaron do you know why he switched?
  rego: It was not impl in all cases. I had example in issue that was
        different in 2 cases where should be same. He didn't have
        whole impl. I think he did the simplest thing
  <fantasai> Mats's comments
  Rossen: If we go with option B (the second option)
  Rossen: Would that be okay dbaron if you're representing Mats?
  dbaron: I'm only reading his comments in issue

  jensimmons: Still trying to wrap my head around. Seems like Miriam
              Suzanne and rachelandrew were advocating for A
  Rossen: A in TabAtkins summary is option 2
  <rachelandrew> option 2 for me (don't think my mic is working)

  fantasai: rego I think case with a difference is case of explicit
            line names creating implicit area.
  fantasai: TabAtkins and I discussed and concluded there wasn't a
            good way to make that work. Would require changes to how
            line names were handled. Couldn't figure out how to not
            cause changes to normal grid
  fantasai: Concluded line names from template are special and special
            for subgrids but explicit line names don't. Which means
            you can handle the partial overlap nicely for template
            areas, but not for area with explicit names
  rego: So original impl from Mats is final?
  fantasai: Yeah. Either way the line names created by template area
            need to be special so we either notice they're excluded or
            clamped for partial overlaps. Seems second is more useful
  rego: Still don't like difference in the example. I understand it's
        useful so maybe it's good enough. I think the difference can
        create confusion.
  fantasai: Ideally we would solve both, but didn't find a good way.
  <fantasai> rego, see
             for problems with the other options

  Rossen: Not hearing strong opinions, but more people toward option 2
  Rossen: Objections to resolving on "Subset parent template to the
          part where it overlaps the subgrid, allowing it to be
          usable" unless there's additional comments
  <fantasai> Example of option 2 -
  Rossen: Objections to Option 2: Subset parent template to the part
          where it overlaps the subgrid, allowing it to be usable?

  RESOLVED: Pick option 2 effectively subset the grid area into the


  fantasai: That's last subgrid so I'd like to propose every
            non-subgrid feature goes to L3 so we can go to CR
  <fantasai> https://drafts.csswg.org/css-grid-2/#alignment
  fantasai: There's a bunch that haven't been edited in. We'd defer
            this ^
  fantasai: There's a handful where we resolved to add features and I
            propose we start a new WD with those and put subgrid L2
            to CR
  fantasai: We didn't edit them in because Grid 1 was a little
            unstable. But none of those features are as urgent as
  <ChrisL> +1 on CR for Grid L2
  <tantek> +1 on CR for Grid L2 with only subgrid added

  Rossen: Proposal: Break Grid L2 down to only contain subgrid
          features. Take L2 to CR. Start L3 with all things moved
  <dbaron> presumably L2 will have the L1 stuff too?
  <tantek> dbaron, that was my assumption too
  <jensimmons> +1 Let's get going on Lvl 3 baby! All the ideas about
               how to make Grid better!!!

  RESOLVED: Start L3 with all work that is in L2 but not about subgrid

  fantasai: Question for ChrisL. Grid 2 is a diff spec and doesn't
            have L1 content. There's a lot in Grid L1 that aren't
            posted to CR.
  fantasai: I don't think I can copy it over yet. Is it okay to
            publish CR as a diff?
  <tantek> I'd be ok with CR as a diff
  <tantek> would rather than CR as a diff than have to wait until "L1
  astearns: I'd wait until we have L1 done. CRs are meant for review
            and diff is hard to review
  <ChrisL> Agreed, delta specs are harder to review
  fantasai: It's easier because it's one fairly isolated feature.
            We're adding this thing. I think it's okay as diff, but I
            want to fold in eventually
  florian: Another is publish subgrid L1 as a CR
  fantasai: No, not making this another spec.
  fantasai: I'll wait if we want.
  <tantek> agree with keeping this as grid L2
  <ChrisL> But okay if explicitly stated all of L1 will be included
  <tantek> I get the feeling most people here are ok with L2 as a diff
  fantasai: We're waiting on a handful of Grid L1, but we're hung up
            on not having tests
  florian: CR should be acceptable as REC and a diff isn't. We should
  jensimmons: I wonder if there's people that love grid enough they'd
              write tests
  fantasai: I think a lot are written and we need to figure out where
            they are
  Rossen: We can wait until next week. It would be nice to make
  fantasai: If it's up to me to do tests I won't get to it until
            mid-Dec at least
  Rossen: Let's get them in 2019 at least
  <tantek> I'd also be ok with L2 as another diff WD with explicit
           status stating we believe the additions are all CR-worthy,
           and that the only change expected before CR is the
           incorporation of all of L1

  Rossen: Reading ChrisL in IRC that he's okay if explicitly stated
          all L1 included. I guess republish with a note? Not sure
          what that looks like for CR
  florian: Not convinced process allows that
  Rossen: Objections to moving grid L2 as CR? We'll figure out format
          but we can resolve to do it now
  Rossen: And from previous resolution it means Grid L2 is the delta
          of 1 and subgrid
  Rossen: Objections?
  fantasai: Union of 1 + subgrid

  RESOLVED: Publish Grid L2 as CR

  Rossen: We'll work with ChrisL to figure out exactly what it looks
  <tantek> 🎉
  Rossen: That's awesome because Grid is awesome

CSS Values 4

Switch advanced attr() to being var()-like
  github: https://github.com/w3c/csswg-drafts/issues/4482

  TabAtkins: Several years ago we defined the more complicated attr()
             functionality where it supplies the type. If you say
             foo=5px we parse as length.
  TabAtkins: No one impl. I realized why.
  TabAtkins: It ends up being high cost for low value. Type checking
             eagerly so at parse time we can reject it it means every
             thing that does grammar checking have to account for
             possibility of attr() being there
  TabAtkins: Lots of fiddly detail work.
  TabAtkins: We did it because we don't have valid at parse time but
             rejected later. We now have that for var(). The var()
             machinery and building on that gives us a lot of tools
             that didn't exist earlier which make attr() easier
  TabAtkins: Precise details of grammar aren't laid out, but core is
             we make attr() act like var(). It makes property
             automatically valid at parse time and we do parse at
             computed time. We validate at that time.
  TabAtkins: Specifying type lets you validate you put the right thing
             in the attr(). Handling attributes elsewhere tends to
             allow garbage and ignore. We maintain that and check type
             and make sure it works.
  TabAtkins: If we base on var() it's the same functionality for
             authors and a significant decrease in implementation
  TabAtkins: I'd like to pursue this change and the impl wants to
             experiment in it
  TabAtkins: Is WG amenable?
  <fremy> I strongly support this!

  emilio: I'm not opposed but concerned about type checking token
          string and then doing parsing again. When I looked at impl
          attr() I suggested doing it like variables in bugzilla.
  emilio: Complexity of doing attr() didn't seem so high either. I'm
          concerned about parsing, tokenization, and then parsing on
  emilio: Other concern is XSS but that happens either way
  TabAtkins: Reason why I don't think first bit is a concern is it
             ends up being identical to custom values and properties
             API. Ideal is it works that way but it's inline
  emilio: I think that's also a concern with custom properties. I
          don't want to block on it, it's mostly theoretical
  TabAtkins: Never say never but I doubt used in performance sensitive

  AmeliaBR: My first concern would be how can we make it work
            logically with the existing use of the attribute function
            in the content property
  AmeliaBR: You've been talking as distinguishing if an explicit type
            is set. More I'm thinking maybe not necessary. If you
            don't have an explicit type the type is assumed string and
            any attribute can be parsed as a string, returned in a
            string. So maybe not an issue because string is always
            valid in content
  AmeliaBR: I'd like to see the exact write up and make sure it makes
            sense in backwards compat without special behavior
  TabAtkins: Not possible w/o any backwards compat because assume
             valid at parse time. Content properties currently invalid
             but use attr() become valid at parse time. It is a
             behavior change if we make unspecified type attr() use
  TabAtkins: Not sure what's best if we split parsing into separate
             function rather then flag it as attr() here. Puts you in
             2 parsing modes based on detail of function grammar.
  TabAtkins: If we think it's okay for behavior change in content
             where you wrote an invalid with a fallback and you're
             relying on that that seems minor. Otherwise good with
             your option.
  TabAtkins: There's some possibilities there, we can experiment
  AmeliaBR: Your example of something suddenly valid is if something
            else in content property would be a parse error. Like
            using slash syntax with alternative text in a browser that
            doesn't support makes a difference if it's parse time error
  TabAtkins: Exactly. You'd no longer have the fallback
  AmeliaBR: I would lean toward having a separate function for the
            type version and use attr() for how it's currently
            supported. Might be problematic for UA that support attr()
            more widely
  TabAtkins: No idea if various printers support. I know no web
             browsers do. I'm not sure impl quality of whole thing
  TabAtkins: But this is a behavior change. It will be off if there's
             a current impl. It's a custom thing or breaking change

  TabAtkins: If no other questions just want to check for objections
             for me creating a full write up of changes. I can do that
             for review next week
  Rossen: Objections?
  fantasai: Summary?
  TabAtkins: There's a lot of possible ways how, but it's a change in
             validation to make it more var() like
  TabAtkins: I'll have a write up fully next week. What's in the issue
             is the right gist
  TabAtkins: It's switch attr() to var()-type validation rather than
             strict parse time validation
  emilio: The fallback might be able to be fix for attr(). Unfortunate
          to add new type of attr() that can't be detected. Nice if
          forced to a valid type. Worth thinking about
  TabAtkins: Yep.
  Rossen: Objections to the approach of switch attr() to var()-type
          validation rather than strict parse time validation
  <astearns> +1 to try this out
  fantasai: Not sure, but let him write it up
  Rossen: TabAtkins there's no objections. Go ahead and write it up
          and we'll look when you're ready

CSS Grid 1

Resolved values of grid-template-rows/columns don't round-trip
  github: https://github.com/w3c/csswg-drafts/issues/4475
  <fantasai> See

  TabAtkins: As spec grid-template-row/column when you asked for
             resolved value you get width of implicit tracks as well
             as explicit. Given you can't spec implicit tracks this
             doesn't make any sense at all.
  TabAtkins: Getting the width of implicit tracks is worthwhile.
             Functionality is reasonable, but a number of useful grid
             things it would be great to get from layout that aren't
             in properties right now.
  TabAtkins: In past proposed things that would require new grid API
             to get
  TabAtkins: Resolved value of grid-templates does not round trip.
  TabAtkins: Options; 1) leave as is. Resolved value is not a valid
             value and confusing because unless you know number of
             implicit rows you don't know where explicit starts
  TabAtkins: 2) Change to only reflect explicit rows on resolved
             values. implicit we leave for a more explicit API
  TabAtkins: 3) Continue to allow grid-template-rows to express
             implicit but change grammar so it's valid. There is some
             value because only explicit are used for auto positioning
             by default. Being able to give bounds to auto while
             sizing outside could be worthwhile
  TabAtkins: Would need to be able to spec when the explicit grid
             starts and stops which would also need to return in the
             resolved value
  TabAtkins: We leave as is, change return of gCS for this so that it
             allows round-tripping either way
  TabAtkins: Need to decide, this was an accident. If we leave as is
             need to be more explicit
  TabAtkins: I prefer changing to be just explicit tracks. I could
             accept any of the 3.

  fantasai: Web compat is a substantial concern. Might be stuck with #1
  emilio: Also I also prefer 2 if we can get away with the compat issue
  TabAtkins: Web compat is always a concern and we might be stuck with
             1. Between 2 and 3 is group okay if we try for 2 and
             revert if web compat proves otherwise?
  oriol: In issue I propose feature which allows define where grid
         line could be. It could place it in another place. I think
         something like this could have its own uses outside this
         issue. However I agree this probably needs more thought and
         be in something like Grid 3.
  oriol: If we want to fix round-tripping we need more urgent for L1
         so it's reasonable to try and remove implicit tracks
  TabAtkins: Your suggestion was option 3, but as you say requires
             additional work. How it interacts is unclear right now
             and a breaking change anyway. If breaking, might as well
             do one that's easier to work with. If we ever want
             explicit/implicit we can do that later

  TabAtkins: Any strong preference for keeping current behavior? Or is
             everyone okay with trying to change gCS and falling back
             to no change if there's web compat problems?
  <dbaron> please make it round-trip correctly :-)
  <florian> I like the proposal
  Rossen: Try it out. It makes sense.
  fantasai: We don't have syntax for that right?
  TabAtkins: Not for 3. No one is suggesting widen the grammar first.
             This is keep as is and have gCS report explicit only or
             have gCS report more accurately
  <fantasai> sorry, I was confused

  Rossen: Resolution would be for give the 2nd option a chance and see
          if there are compat reasons to instead keep current
  Rossen: Other opinions or objections?
  emilio: No objections but I want note sure both Gecko and
          Chromium...info from gCS is not useful. Both Chromium and FF
          have special dev tools because gCS is not enough.
  Rossen: We can look at extending OM for grid
  Rossen: I think you're pointing out more general issue. I don't
  <emilio> https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl
  TabAtkins: Point is valid in that what's currently returned is not
             enough for current use cases. So we're not losing
             anything and we should look into more advanced on
  Rossen: Agreed
  Rossen: Objections?

  RESOLVED: Give the 2nd option a chance and see if there are compat
            reasons to instead keep current behavior

  <TabAtkins> emilio, I'd love to with with you and jensimmons or
              anyone interested in this to figure out what devtools is
              using and how we could expose that to users.
  <emilio> TabAtkins: fwiw, this is the API exposed to devtools:
           via https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#322

Spaces in grid-template-areas serialization
  github: https://github.com/w3c/csswg-drafts/issues/4335

  fantasai: Want to clarify how spaces are handled. There's no
            compatibility. We said serialize between tokens we do a
            single space no matter if it's needed
  fantasai: Want to confirm with WG
  astearns: Makes sense to me
  emilio: Seems weird to change string because we don't change string
          in other places
  TabAtkins: You do change the string somewhat. You don't if parsing
             splits tokens correctly. But you trim spaces at end and
             collapse many to one
  oriol: In issue #3261 we resolved against preserving precise string
         in favor of normalizing. Just wasn't clear on what to do with
  TabAtkins: Thanks
  astearns: emilio?
  emilio: No objections
  astearns: Other concerns?
  astearns: fantasai has comment at end with proposal
  astearns: Objections to this?

  RESOLVED: Specify serialization as proposed in
Received on Wednesday, 13 November 2019 23:29:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:17 UTC