W3C home > Mailing lists > Public > www-style@w3.org > January 2021

[CSSWG] Minutes Telecon 2021-01-06 [css-cascade-5] [css-scoping] [css-grid] [css-pseudo] [css-shapes] [cssom] [css-overflow] [css-break] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 7 Jan 2021 05:40:53 -0500
Message-ID: <CADhPm3vcQtj9__47pOMq-18ZkGj-k=w10GLKr7jKwKAoD7xZSg@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 Contain & CSS Scoping
-------------------------

  - There are proposals for Container Queries (
https://github.com/w3c/csswg-drafts/issues/5796 )
      and Light-DOM Scope ( https://github.com/w3c/csswg-drafts/issues/5809 )
      available for review prior. Everyone is encouraged to read the
      proposals and engage on github.
  - RESOLVED: Publish FPWD of L5 of Cascade

CSS Grid
--------

  - RESOLVED: Stretch alignment doesn't disable the aspect ratio. It
              can distort it if the other axis is constrained (Issue
              #5713: Note implies losing an aspect-ratio when it
              shouldn't?)

CSS Pseudo
----------

  - RESOLVED: Add an :autofill pseudo-class to selectors (Issue #5775:
              :autofill pseudo-class)

CSS Shapes
----------

  - RESOLVED: Merge this PR into next level of Shapes (Issue #5674:
              Allow CSS grammar for path shapes)

CSSOM
-----

  - RESOLVED: Go with Emilio's naming and Sam's amendment (Issue
              #5649: The way CSSStyleDeclaration exposes properties is
              not ideal)

CSS should define and use consistent terminology for words like
    "deprecated", "obsolete"
---------------------------------------------------------------

  - RESOLVED: Close no change but open issues on spec areas where it's
              not clear what the intent was for a deprecation (Issue
              #5644)

CSS Overflow
------------

  - RESOLVED: Add the box keywords to the overflow-clip-margin (Issue
              #5801: Add box-edge values to overflow-clip-margin)

Cascade / Pseudo-elements / Values / Fragmentation
--------------------------------------------------

  - RESOLVED: Color inherits according to first line inheritance.
              currentColor keys off value of that fragment per
              fragment (Issue #1510: currentColor when fragments have
              different colors)
  - RESOLVED: Have font-relative units key off the font size per
              fragment (Issue #1510)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0000.html

Present:
  Rossen Atanassov
  Tab Atkins-Bittner
  Tantek Çelik
  Hui Jing Chen
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Mason Freed
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Dean Jackson
  Ian Kilpatrick
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Scribe: dael

  astearns: I think we have enough people to get going
  astearns: Does anyone have any changes to the agenda?
  astearns: Happy new year and thanks everyone for joining the first
            meeting of 2021
  astearns: I did send a message about extended virtual meetings next
            month. Unless I hear differently I'll set those up at the
            end of the week.

CSS Contain & CSS Scoping
=========================

5-minute intro on new Cascade Layer draft, and two issues put up for
    TAG review
--------------------------------------------------------------------
  Cascade 5: https://drafts.csswg.org/css-cascade-5/
  Container Queries: https://github.com/w3c/csswg-drafts/issues/5796
  Light-DOM Scope: https://github.com/w3c/csswg-drafts/issues/5809

  miriam: The first one is adding cascade layers to cascade 5 spec. I
          have a first ED of the spec up on github and would love some
          review.
  miriam: It links to a number of issues we can discuss, maybe at F2F.
          Would love feedback to push forward
  <florian> [Only briefly looked at the cascade 5 draft, and plan to
            spend more time on it later, but so far so good]

  miriam: Next are 2 proposals I put related to cascading. One is a
          proposal pushing container queries forward and the other an
          approach to scope in the light dom.
  miriam: Fairly different from other scope proposals.
  miriam: Both of those I would love feedback and discussion. Would
          love a sense of interest and if we should keep pushing

  fantasai: I propose we put cascade 5 for fpwd either this or next
            week. It reflects the discussion and good to get
            officially published
  <fantasai> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fdrafts.csswg.org%2Fcss-cascade-4%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-cascade-5%2F
  astearns: Is it diff spec?
  fantasai: It has everything. Because cascade 4 is stable didn't need
            to do much
  astearns: I'd be happy to do fpwd. Anyone want to wait till next
            week or review or do we resolve today?
  astearns: Prop: FPWD of L5 of Cascade
  astearns: Objections?

  RESOLVED: Publish FPWD of L5 of Cascade

  <chrishtr> Congratulations!
  <miriam> 🎉

  astearns: Any other initial reactions to the new proposals?
  florian: To the question of if she should continue pushing on this,
           yes.

  Rossen: We did get the scoped proposal in tag and we will be talking
          about it and reviewing shortly so expect engagement and
          feedback soon
  miriam: Thank you
  astearns: Yes, both have been put up for tag review so we should
            expect to see something from tag for both
  miriam: Should I also post cascade layers for tag review?
  Rossen: Generally the earlier you engage with tag the better. There
          are plenty of folks in both groups so having the home court
          advantage we see early work. But yes, please engage with tag
          once explainer is ready
  fantasai: Since tag is dealing with turnover and we have a bunch of
            open issues maybe we go through the issues next month and
            then give to tag.
  Rossen: If this is an early review or a design review it depends.
          You're suggesting stable and up for review. I was suggesting
          early draft review which is lighter weight and gets some
          feedback
  iank: Agree with Rossen that earlier is better
  miriam: Okay, will work on it

  astearns: Thank you for all this, miriam, this is great stuff
  <Rossen> huge +1 on this being great work!! Thank you miriam & co.

CSS Grid
========

Note implies losing an aspect-ratio when it shouldn't?
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5713

  fantasai: Have agreement that stretch on its own in single axis
            shouldn't cause you to lose aspect ratio.
  fantasai: I think we're clear on that and it's editorial. We did
            have implementors doing something different
  <fantasai> https://github.com/w3c/csswg-drafts/commit/f5823bc7d64106a160b5473a972bbb744f27262b
  <fantasai> clarification ^
  <fantasai> https://github.com/w3c/csswg-drafts/commit/93ea82e30baf4c9b887a5d60e89f90a5411e94f7
  <fantasai> additional fix in css-align ^
  iank: I filed this because we were looking how stretching works in a
        single axis internally. Noticed all implementations of grid
        throw away aspect ratio in this condition. I think a lot of
        confusion was from note which is being fixed
  iank: 10-15 tests in the suite which are testing the broken
        behavior. I'm prepared to fix the tests but it would mean all
        impl will fail the tests
  iank: If we have agreement this is correct, then this is an fyi to
        fix impl

  dholbert: Does this make grid more like flexbox?
  dholbert: More consistent or shifting?
  iank: Yes, makes them more consistent. If you stretch image in one
        axis the aspect-ratio is typically preserved
  fantasai: I think the fix to the note is correct. Will this change
            behavior for an image with no alignment but it is in a
            grid? Normal in both axis. If that behavior would change
            there's web compat issue
  iank: Normal in both axis doesn't imply stretching so it's fine.
        This is only when stretching in one axis or the other
  Rossen: And stretching only?
  iank: Correct. The weirdness here is that if you stretch in the
        inline axis for a grid item the image was distorted. You have
        to opt into this so I'm fairly sure it's web compat. But there
        are a lot of tests testing the broken behavior

  astearns: Would it make sense when you update tests for you to open
            bugs on all engines?
  iank: Depending on set up tests themselves failing might cover. Does
        cover FF. But I'm happy to file bugs as well
  astearns: Anyone with concerns?
  fantasai: Proposal: stretch alignment doesn't disable the aspect
            ratio. It can distort it if the other axis is constrained
  astearns: Objections?

  RESOLVED: stretch alignment doesn't disable the aspect ratio. It can
            distort it if the other axis is constrained

CSS Pseudo
==========

:autofill pseudo-class
----------------------
  github: https://github.com/w3c/csswg-drafts/issues/5775

  astearns: This is emilio who is likely not here
  tantek: Are there particular concerns?
  florian: Given it exists and unlikely to be removed makes sense to
           have it. I'm wondering about privacy concern of it. Content
           of field isn't changed but if it is filled by a human or
           something saved might have privacy considerations
  fantasai: I feel there are other ways to get that information. If
            all forms are filled in a second it is autofill
  tantek: That does sound like a concern to raise. Sounds like :visited
  florian: Yes, just thinking about it.
  tantek: At a minimum I think it's excellent feedback. Maybe they can
          document it as a potential privacy concern.
  tantek: It would be good to get that as feedback from the WG
  florian: I'll drop it in GH

  fantasai: Should we resolve to add the pseudo class?
  astearns: Prop: Add an :autofill pseudo class to selectors

  RESOLVED: Add an :autofill pseudo-class to selectors

CSS Shapes
==========

Allow CSS grammar for path shapes
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5674

  TabAtkins: I've been looking for something like this for a while.
             SVG path is a little weird. Right now you have to do path
             as a string and you can't concat a string it means you
             can't build path with variables
  TabAtkins: User friction thing
  TabAtkins: Proposal, not from me, from Noam, with good syntax
             converting svg syntax to css friendly version. I really
             like how it looks. Extensible to logical coordinates. I
             think this is a nice good approach and I'd like to add to
             spec

  fantasai: I reviewed the PR and discussion and I think it's a good
            proposal, well specified

  dino: I left some minor comments, but don't care if they're not
        addressed.
  dino: If one was to animate; this was defined as equivalent to SVG
        path so thus if you animate between the svg rules apply and
        thus you need same number of segments with same type?
  TabAtkins: Yeah
  dino: Therefore a curve, if a command was curve xy via something if
        one gave 2 coordinates and the other 1 they would not animate,
        right?
  dino: The distinction between quadratic and cubic is number of
        params, not command type.
  dino: Maybe a bit strange curve says where it's going first. But
        again it's minor. I'll mention it, but I don't care
  astearns: And one of the reasons to take the PR is so we can open
            more issues to make amendments. I assume animations is not
            defined in PR so we'd unpack in spec.
  TabAtkins: Yeah
  astearns: dino you mentioned you made comments. I saw one on PR
            about typo
  dino: They're all minor and can be issues after

  astearns: Hearing agreement. Objections to merge this PR?

  RESOLVED: Merge this PR into next level of Shapes

CSSOM
=====

The way CSSStyleDeclaration exposes properties is not ideal
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5649

  astearns: This issue is full of Europeans. Anyone can take it?
  TabAtkins: I'm happy to run it since our people are okay with it
  TabAtkins: emilio points out that the way CSS style declarations
             expose properties is weird. Per current CSSOM definitions
             all properties and @rules are merged into same object and
             they work or don't
  TabAtkins: Proposal to solve is split apart interfaces for style
             rules and each @rule that uses .style so they are
             distinct name spaces
  TabAtkins: Sounds good to me. Anders says seems fine because
             exposing all @rule on every style rule seems weird as well

  TabAtkins: Sorry, we resolved on overall proposal
  astearns: emilio added specifics
  TabAtkins: Specific proposal is add a batch of interfaces named
             [reads from
https://github.com/w3c/csswg-drafts/issues/5649#issuecomment-742760748
]
  <fantasai> wfm
  TabAtkins: Use those as extensions of css style declarations and
             they have appropriate descriptor names. Looking for
             opinions on naming.
  TabAtkins: I think names are fine
  astearns: Anyone else have an opinion?
  fantasai: Sam had an opinion to have everything else named
            descriptors. That's the counter proposal. That also works
            and I think slightly better
  astearns: Proposal: Go with emilio naming and Sam's amendment

  RESOLVED: Go with emilio naming and Sam's amendment

CSS should define and use consistent terminology for words like
    "deprecated", "obsolete"
===============================================================
  github: https://github.com/w3c/csswg-drafts/issues/5644

  florian: Raised a while back by Mike Smith indirectly because he was
           confused. Used deprecated in a few places and the meaning
           has changed over time. Should we use deprecated for all the
           meanings or do we be more specific
  florian: Could be using as "this feature is bad idea but we have it"
           or "this feature is old bad name but we're documenting it".
           Or "we're documenting it but browsers are removing it". Or
           in HTML "we're not specifying this feature but we're
           telling you it used to exist".
  florian: The first two are the ones we use. Maybe that's fine. Maybe
           we should pick it to mean one.
  florian: No strong opinions on which way, but this is the question
  florian: Reason Mike Smith reacted is we documented as deprecated
           something with an old name but he thought we meant this is
           old do not use. That's where potential need to distinguish
           came from

  fantasai: We use in English meaning to express disapproval. If an
            implementation required to have it, then that's separately
            documented via RFC2119 terminology. Either must impl or
            should impl. We're clear. If we discourage users that's
            separate term. Deprecated is basically a value judgment
            and an indication of preference from WG
  fantasai: I think we're clear on what's required and what's
            discouraged.
  florian: As long as we keep being explicit for deprecated feature
           normative requirements we're good.
  florian: I'm fine closing no change, but it was raised

  <tantek> should we escalate to the TAG to provide a more precise
           definition of "deprecate(d)" and "obsolete(d)" for
           consistent use across W3C specs?

  smfr: I think it's important to distinguish recommendation for
        authors and instructions for implementors. Maybe something
        being obsolete should only be things in spec and deprecation
        is for UAs.
  florian: We do distinguish but we do with explicit text, not keywords
  fantasai: We say UA must or should and users should or should not. I
            don't think we use deprecated in the place of must or
            should. Maybe some image angles will become obsolete.
            Otherwise we use deprecated where we prefer people didn't
            use it but you might have to in certain contexts because
            it's out there
  smfr: A clear distinction between browsers might have to impl and
        authors might have to use is useful
  florian: We absolutely should have that distinction. But do we do it
           through terminology or through text?
  fantasai: We say it's deprecated and you have to implement or and
            you shouldn't implement. The conformance requirements is
            expressed with RFC2119
  <tantek> should we stop using those terms then?
  smfr: I think better explained with examples
  astearns: We do most often add text describing our intent. In cases
            where it's not clear we can open issues to make that
            better. But not come up with specific spec terms
  astearns: I think I would rather not a specific term because
            sometimes people don't follow links for meaning so it
            could hide things that are in prose

  astearns: Proposal: Close no change but open issues on spec areas
            where it's not clear what the intent was for a deprecation
  tantek: Should we discourage future use of those terms?
  fantasai: When we say something must be impl but authors shouldn't
            use...must be impl like system colors but this is a bad
            idea so it shouldn't be in your css vocabulary
  tantek: Should we discourage editors from using deprecated or
          obsoleted?
  fantasai: I don't think so. They have useful meanings in English
  astearns: They're useful terms we're just not loading them with
            anything besides standard English meaning
  astearns: Objections?

  RESOLVED: Close no change but open issues on spec areas where it's
            not clear what the intent was for a deprecation

  <tantek> no objection, though it does feel odd to use terms as
           "English meaning" that are used more precisely by other
           specs

CSS Overflow
============

Add box-edge values to overflow-clip-margin
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5801

  fantasai: A lot of confusion in chrome bug by authors that expected
            border edge to a box [missed]. It has borders and radius
            and it clips to the inner edge. In corner with curve it
            clips to curved edge. Looks a bit weird if contents are
            only replaced element. Why doesn't it clip to content edge?
  fantasai: If you spec padding and borders on replaced element
            because it curves the edges of the box including content
            the replaced element will get a curved edge. But if you do
            it on a container the contents still show.
  fantasai: Frequently wanted. We have overflow clip margin that takes
            a length and lets you clip a little outside the box. Could
            add content-box padding-box and border-box as keywords
            that sets the margin to the appropriate offset.
  fantasai: That's the use case and proposal. Question is do we want
            to do that?

  astearns: Keywords alone or supply a length?
  fantasai: Keywords alone, length, or combo

  florian: Reasonable. What is implementor interest?
  chrishtr: I think it's okay. Tried implement a couple months ago and
            it was easy
  smfr: I need more pictures, hard to understand. Insetting the inner
        curved border radius by some amount?
  chrishtr: Top of issue green and red; they want inner and outer
            curve to match
  smfr: White stripe is padding and they want that curved?
  chrishtr: Yep
  myles: It's possible to achieve that. This proposal is to make it
         easier?
  fantasai: Yeah, you'd need a wrapper element to get that otherwise.
            And you'd have to match the radius correctly. You can do
            it but it's awkward
  smfr: Always inset not outset?
  fantasai: A positive value outsets from the edge it would clip. So
            you can outset or inset. Proposal here is add keywords
            that match the box edge
  smfr: And if you are outside child elements paint on top of border?
  fantasai: Yeah
  smfr: And this is ones without overflow hidden?
  fantasai: You'd need to apply a clip
  smfr: Also about clip path?
  florian: Not clip path. Overflow
  smfr: Inset the rectangle and recompute border radius that's okay.
  fantasai: Just about inset and outset from border edge for overflow
            property
  smfr: Okay
  <fantasai> https://drafts.csswg.org/css-overflow-3/#overflow-clip-margin

  dholbert: It sounds like this is clipping padding separate than
            clipping content?
  fantasai: Currently have overflow clip margin. If we allow a
            content-box value we would need to inset. It would clip
            contents, not the element.
  chrishtr: It already only clips content. This changes dimensions of
            clip. Size and border radius
  dholbert: Padding is clipped at curved border and that controls
            where content is clipped
  chrishtr: Padding is clipped as normal.
  fantasai: By the background-clip
  chrishtr: What you can already spec as different rectangles. This is
            only to apply to content
  Rossen: Is there any additional implications to box shadow?
  fantasai: Doesn't effect. Only effects content

  florian: We just talked through how it only effects normal border
           box. In Backgrounds 4 we had corner shape property to cut
           at an angle. Expectation is will have new corner shapes
           that might make impl a bit harder.
  florian: Doesn't change usefulness, but does it change the concern
           on impl?
  chrishtr: Does this thing let you spec the angle?
  florian: Only switch from rounded to a straight diagonal line right
           now. May expand to different corner shapes.
  myles: Not sure there would be consensus this property you described
         would grow. Used to have more values and we got rid of them.
         I'd be surprised if we add a lot more
  chrishtr: I would agree. It already has the need to geometrically
            expand or contract without complex code. I don't think we
            would spec difficult cases
  florian: Cool. I was just hoping that we weren't missing a case for
           complexity
  fantasai: Drawing the complex border is a bigger problem then
            changing the clip

  astearns: I think I heard questions from each implementor
  astearns: Sounds like consensus to add these keywords to
            overflow-clip-margin
  astearns: Concerns?
  astearns: Add the box keywords to the overflow-clip-margin
  astearns: Objections?
  dholbert: border-box, padding-box, content-box?
  fantasai: Yes
  fantasai: padding-box is default

  chrishtr: Can the syntax be implemented incrementally? Someone
            implements lengths and add this later?
  fantasai: Should be fine. As long as you don't parse the syntax you
            don't implement it's good

  RESOLVED: Add the box keywords to the overflow-clip-margin

Cascade / Pseudo-elements / Values / Fragmentation
==================================================

currentColor when fragments have different colors
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1510

  <fantasai> https://jsfiddle.net/ehzknab5/2/
  fantasai: Bunch of properties that can take currentColor. The
            rendering in FF that's screen-shotted is outdated. If you
            load newer FF all properties are correctly handled
  fantasai: Seems to be what author expect. Implemented by one
            browser. I'd like to resolve that's how it's done
  astearns: Different opinions?
  astearns: I'd rather not resolve on "do what is says in the issue".
            Summary?
  fantasai: Proposal: color inherits according to first line
            inheritance. currentColor keys off value of that fragment
            per fragment
  astearns: Concerns? Objections?

  RESOLVED: Color inherits according to first line inheritance.
            currentColor keys off value of that fragment per fragment

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1510#issuecomment-689042237
  fantasai: Related is for fonts which is comment from oriol ^
  fantasai: If first and third line match it's implemented by that rule
  astearns: Second is do the same thing for font relative units?
  fantasai: Yes, key off font size per element
  astearns: Objections?

  RESOLVED: Have font-relative units key off the font size per fragment

  myles: First letters are big. If you use em you get the big size for
         that element
  fantasai: This is first-line. It's the innermost element. There are
            issues around that and I think they're filed. But it's a
            separate kind of mechanism than first-line
  astearns: We're at time. Should we walk back resolution, myles?
  myles: No, we can continue

  astearns: Thanks everybody for calling in and we'll talk next week
Received on Thursday, 7 January 2021 10:41:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 7 January 2021 10:41:39 UTC