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

[CSSWG] Minutes Telecon 2020-11-04 [css-flexbox] [css-contain] [resize-observer] [css-logical-1] [css-sizing] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Nov 2020 21:38:01 -0500
Message-ID: <CADhPm3tG0sxcqb26D-sHT5MVr77dRYDhWmMWDkavfpT=F-PUxQ@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.
=========================================


Flexbox
-------

  - RESOLVED: Close this issue as an editorial change (Issue #5663:
              Should definite cross size be used to compute flex
              item's transferred size suggestion?)
  - RESOLVED: Add an appendix to flexbox spec for the webkit prefix
              properties (Issue #5634: Move -webkit- prefixed aliases
              into flexbox?)
  - RESOLVED: Add these to the appendix as MUST or MAY depending on
              implementation [web exposed implementations are a MUST,
              otherwise it's a MAY] and SHOULD NOT for authors. Add
              details about how they're not simple aliases (Issue
              #5634)

CSS Contain
-----------

  - RESOLVED: Uncomment possibility of an exception and accept the PR
              (PR #5643: Clarify how sizing containment works)
  - The group agreed that allowing a browser to search content that is
      currently hidden when doing find-in-page and
      ScrollToTextFragment was a valuable use case to solve (Issue
      #5595: Proposal: content-visibility: hidden-matchable). Before
      reaching any resolution, though, there is a desire to explore
      further if there are other types of finding hidden content which
      should be included such as searching by text fragment ID. There
      also needs to be a review of the proposal to ensure that it will
      provide a good experience when it interacts with various
      accessibility tools.

Resize Observer
---------------

  - gregwhitworth will review PR #4150 (Remove SVG specific text) to
      see if it needs to be re-written.

Logical Properties
------------------

  - RESOLVED: Add an optional line in propdef table for logical
              property groups (Issue #2822)

CSS Sizing
----------

  - There needs to be some additional exploration of use cases for
      issue #5650 (Add fill(<length-percentage>) / rename stretch
      keyword for width/height?) prior to a resolution. The group was
      leaning toward keeping the keyword name as 'stretch'.
  - RESOLVED: Close this issue as fixed (Issue #3731: How should
              inline-axis intrinsic sizing work for 'fit-content' and
              'fit-content()'?)

Values & Units
--------------

  - RESOLVED: Interpolate ratios using logarithm (Issue #5953: How to
              interpolate <ratio>?)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Nov/0002.html

Present:
  Joseph Arhar
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Hui Jing Chen
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Megan Gardner
  David Grogan
  Chris Harrelson
  Dael Jackson
  Vladimir Levin
  Daniel Libby
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Myles Maxfield
  Cameron McCormick
  Florian Rivoal
  Miriam Suzanne
  Greg Whitworth

Regrets:
  Daniel Holbert

Scribe: dael

  astearns: Anyone have any changes or additions to the agenda?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5630
  fantasai: Request. There are some questions from privacy group. It
            would be nice to have a party from each impl answer the
            questions in the original post
  fantasai: I need webkit and blink answers
  chrishtr: I can answer
  astearns: Thanks
  chrishtr: Thanks for bringing attention

  astearns: One additional item. As we mentioned on past calls we have
            /tr publications that are out of date. I've discussed
            privately with people. I'm going to have to start to call
            people out publicly.
  astearns: CSS Scoping has updates in ED and it's 6 years out of
            date. TabAtkins do you have a plan?
  TabAtkins: Soon. I don't have a timeline. It's been on my list. It
             will get up there when I can
  astearns: Hopefully it can be elevated above some others on the list

Flexbox
=======

Should definite cross size be used to compute flex item's transferred
    size suggestion?
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5663

  TabAtkins: There's a question about terms we're using in 2 parts of
             spec. In 9.8 where we define extra ways for lengths to
             get definite we talk about outer cross size. In earlier
             sections for min size one of the conditions was stated as
             relying on cross size being definite. Unclear if one
             being definite was meant to apply to other term.
  TabAtkins: Edited spec for more consistent. Didn't have right terms
             back then and said "property" but what we want is
             preferred size. dgrogan confirmed it looked good. Unless
             other thoughts I think we can close with this fix
  astearns: Original commenter just replied saying good
  fantasai: I say we close as editorial

  astearns: Proposal is close this issue and an editorial change
  astearns: Objection?

  RESOLVED: Close this issue as an editorial change

  astearns: Thanks for the updates

CSS Contain
===========

Clarify how sizing containment works
------------------------------------
  github: https://github.com/w3c/csswg-drafts/pull/5643

  florian: A while back Mats pointed out the text of size containment
           wasn't clear. Phrasing was handwavy. Long discussion in
           github of how it could be interpreted and which is right.
  florian: Made a PR which clarifies. Reviewed by fantasai and I think
           TabAtkins. Reasonably confident it's good
  florian: There was a longer discussion that maybe original intent
           wasn't right because possibility size containment was
           toward container queries and maybe wanted to ignore things
           like grid-track-sizing instead of treat grid as empty. That
           would make it nicer for when element queries are a thing.
  florian: Separate GH about if container queries is possible here
  florian: Could have css contain open a door for possible exceptions
           in other specs. Size as if empty but we apply all
           properties unless stated otherwise in other specs.
  florian: Specs like grid are further back in rec track so we don't
           consider it in css contain or we close the door now
  florian: Except for that I'm confident text is good. Didn't get
           review from Mats unfortunately. Hard to read as a diff
           because a lot of red but there's a link to read
  florian: Would like approval to merge unless comments.

  fantasai: Should this go into contain 1 as well?
  florian: Yes. Editorial compared to intent of spec. Editorial
           compared to text is debatable. But yes to get into L1

  chrishtr: Does the PR make it any different from browser behavior?
  florian: Nothing interop changes. Corner cases about size
           containment to grid container with sized tracks which are
           different between FF and Chrome which would change
  chrishtr: Are they enumerated?
  florian: I know them and can write them down. I plan to write tests
           to expose details
  astearns: Not currently any tests?
  florian: Tests that fail in FF and remain valid. Test are for
           original intent which was not clearly expressed
  florian: Now it's more precise we can write more tests
  astearns: Usually when we have an issue and decide on a fix we close
            and put needs test cases. Since this is a PR I'm worried
            someone looking for test cases wouldn't find it to write.
            I wonder if it would make sense to create an issue for
            testing where it enumerates the new cases
  florian: I intend to write tests in a day or two of resolution, but
           I'm okay to have more
  astearns: If that's the case then no need

  astearns: Any other comments?
  heycam: I can ping Mats but don't want to block

  astearns: Proposal: Accept the edits and create tests
  florian: With open possibilities for other specs to exempt from the
           rules or close the door?
  heycam: Always possible for specs to override?
  florian: It's nicer to call it out, but even if we don't you can
           still do the override
  astearns: Since it's not clear we'll go ahead maybe leave it in as a
            we don't know yet
  astearns: Other opinions?
  astearns: PR has the exceptions can be made?
  florian: Commented out. I need to un-comment
  astearns: Proposal: Uncomment possibility of an exception and accept
            the PR
  astearns: Objections?

  RESOLVED: Uncomment possibility of an exception and accept the PR

  florian: Thank you

Resize Observer
===============

Remove SVG specific text
------------------------
  github: https://github.com/w3c/csswg-drafts/pull/4150

  astearns: I think this was on to see if we should re-work or close.
  astearns: gregwhitworth have you had a chance to look?
  gregwhitworth: Have not, I'll review it tonight
  astearns: afaict it's a change we need to make but a question of if
            we can land the PR
  gregwhitworth: I'll review. Because it's over a year I don't know

  florian: I put it on the agenda because plinss pointed out it's in
           the main repo which causes slowdowns. So we should land or
           delete it
  gregwhitworth: Sounds like a plan. I'll get it tackled

Flexbox
=======

Move -webkit- prefixed aliases into flexbox?
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5634

  TabAtkins: Currently the whatwg compat spec defines the aliases from
             old webkit prefixes for flexbox because required for
             compat. gsnedders asking to move out of compat and into
             flexbox
  TabAtkins: In general we're okay with putting compat in a spec
  TabAtkins: I'm fine
  TabAtkins: I would like to put in appendix as fantasai pointed out
  TabAtkins: Two things, should we move? If yes, what level of wording
  astearns: Add an appendix to flexbox spec for the prefix properties

  RESOLVED: Add an appendix to flexbox spec for the webkit prefix
            properties

  TabAtkins: Not consistent with 2019 usage for legacy. We lean toward
             MUST. Images has SVG with MUST but writing mode was using
             MAY. We should make the usage consistent but figuring out
             how is a separate issue
  TabAtkins: For now I'd like a MUST since that seems the more
             consistently used. Later can have issue to make all
             consistent
  florian: Makes sense and so does having MUST as default since we
           wouldn't spec it if it wasn't necessary
  fantasai: Yeah, but if you're css renderer who isn't doing web
            content you won't care
  heycam: I think it makes sense MUST. -webkit-appearance type there
          could be impl with problems but I don't think this is a case
  fantasai: There is a renderer who isn't compat with web but does
            flexbox. I don't want to make them non-conformant

  iank: When you move this into flexbox make sure you don't list as
        aliases, they're more complex then that. Compat spec was lying
        a bit there.
  TabAtkins: You're saying compat spec is incorrect?
  iank: My quick reading of it I believe so. My understanding of how
        we impl is if you've got display-webkit-box you don't look at
        webkit ordinal and then order, you only look at ordinal. You
        look at one set of properties as a whole. It's a higher level
        switch. Compat spec says they're alias which is incorrect
  heycam: I don't remember off the top of my head but Daniel did the
          implementation
  TabAtkins: We'll resolve it when we do edits
  iank: Yeah, just an FYI. I can give more detail and hacks when
        you're writing

  heycam: WPT doesn't have tests on -webkit-flex things so tests would
          be good.

  fantasai: If they're not simple I'm rather against a MUST for non-web
  TabAtkins: I'd propose putting as a MUST for web exposed impl and
             MAY or SHOULD for others
  fantasai: Sure. Go with MAY
  astearns: Proposal: Add these to the appendix as MUST or MAY
            depending on impl and SHOULD NOT for authors. Add details
            about how they're not simple aliases
  florian: If you support is may or must depending on context but if
           you do you have to do it how iank described?
  fantasai: Yeah
  astearns: Concerns? Objections?

  RESOLVED: Add these to the appendix as MUST or MAY depending on
            implementation and SHOULD NOT for authors. Add details
            about how they're not simple aliases

  astearns: If we uncover any differences between how blink and gecko
            support these it would be good to tease it out
  TabAtkins: Yep
  heycam: Might be good to file an issue to capture the discussions
  astearns: I'm happy to have first attempt go into spec and if there
            are concerns we should open an issue
  heycam: Okay

Logical Properties
==================

Spec should introduce propdef table notation for logical properties
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2822

  fantasai: Need to ID properties that belong to logical property group
  fantasai: One way is shorthand in prose but suggested we add a new
            link to propdef tables for properties part of logical
            property mapping group with same ID
  fantasai: If we do this I think it should be optional in propdef so
            we don't have a bunch of empty fields
  <iank> An example of only looking at the "set" of properties:
         https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20-webkit-box%3B%22%3E%0A%20%20%3Cdiv%20style%3D%22-webkit-box-ordinal-group%3A%202%3B%22%3EA%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22order%3A%203%3B%22%3EB%3C%2Fdiv%3E%0A%3C%2Fdiv%3E

  astearns: Do you agree with oriol about in associated physical
            properties?
  fantasai: Of course. They're part of the logical property group
  astearns: How many specs, how many properties?
  fantasai: Backgrounds & borders, positioning, scroll-snap, and box
            are the only one affected, I think
  fantasai: border, margin, padding, scroll snap margin and padding,
            inset properties
  fantasai: Most specs not affected which is why I think when making
            propdef don't include unless needed
  <oriol> overflow too
  astearns: Opinions?
  astearns: oriol mentioned overflow
  fantasai: Yeah

  astearns: Proposal: Optional line in propdef table for logical
            property groups
  fantasai: Yeah. May fiddle with name.
  heycam: I also see groups for min size and max size?
  fantasai: Yeah, sizing also affected

  astearns: Objections to adding a line?

  RESOLVED: Add an optional line in propdef table for logical property
            groups

  <fantasai> I'm thinking maybe it should be called "Mapping Group"
             and we should call logical property group "logical
             property mapping group" or something...

CSS Sizing
==========

Add fill(<length-percentage>) / rename stretch keyword for
    width/height?
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5650

  fantasai: As I was going through some of sizing occurred we might
            want to have the ability to represent the size as I want
            you to fill this length or %. What this would do which is
            different is account for margins
  fantasai: We have a keyword currently called stretch which should be
            same name as function. Gives the fill of the block
            element. Introduce a function which does same but fill
            arbitrary elements. Call it fill or stretch depending on
            how we name the keyword. Should match.
  TabAtkins: Sounds reasonable to me

  astearns: Sounds reasonable, but that's a low bar. I think I'd like
            to see use cases
  fantasai: Sure. Max-height fill 100vh on images. Long scrolling doc
            with images want to make sure they're not bigger then the
            viewport. What if you want to account for margins? You can
            subtract for a length but with this you can subtract the
            margins.
  fantasai: We can discuss later but I think we need to decide if we
            want to keep stretch or fill as keyword for the overall
            behavior
  chrishtr: Could you add the examples to the issue?
  astearns: The 100vh one is.

  astearns: I'm partial to stretch term. Fill isn't quite the meaning
            in my mind. I don't know if anyone else has opinion
  oriol: I prefer to keep stretch because matches the keyword in
         justify/align-self which is same behavior w/o max width and
         height properties aren't taken into account. Easier for
         authors if keep same name.
  astearns: A little concerned about weird edge cases where stretching
            or accommodating margins makes things more complicated.
            Just a general worry this isn't as simple as stated.

  astearns: Other opinions?
  astearns: Shall we go back to the issue for now?
  astearns: Since fantasai mentioned you're happy not to resolve today
  fantasai: Yeah, I mentioned that
  astearns: Let's keep this open and talk through more use cases and
            edge cases.
  astearns: If anyone interested in drawing out impl of this that
            would also be useful

How should inline-axis intrinsic sizing work for 'fit-content' and
    'fit-content()'?
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3731

  fantasai: I believe the issue is solved. I'm looking for
            confirmation we're okay. Seemed there was some confusion
            but I answered the question. oriol looked and thought it
            was fine I think. I'd like to close the issue at some
            point. I don't believe further edits are necessary
  astearns: dbaron isn't on. We could close and if there is anything
            additional he can re-open with a comment
  astearns: Any objection to close this as fixed?
  astearns: And keep commenter response pending tag on it

  RESOLVED: Close this issue as fixed

Values & Units
==============

How to interpolate <ratio>?
---------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4953

  TabAtkins: Currently the value and units spec defines that ratios
             are interpolated by dividing and interpolate the number.
             Bad. It's simple but has bad properties. Grossly
             asymmetrical between tall and wide. Tall has 1-0 range
             and wide is 1-infinity
  TabAtkins: If going from 1-1 to 10-1 if it goes tall it spends most
             of it's time being close to square. Takes a long time to
             go 1 -> .1 But if you're going wide you're spending most
             of the time close to 10
  TabAtkins: A much better way to preserve the symmetry is to take the
             log of the division results and interpolate that and use
             the exponent to get back to the ratio. Gives you
             identical behavior. Makes sure if you're going 2-1 that
             halfway is square
  TabAtkins: Suggestion from dbaron has other asymmetries. If you want
             details it's in the issue and oriol has examples of where
             the asymmetry comes in
  <fantasai> oriol made demos at
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8634
  TabAtkins: Would like to transition ratios using log of result. I
             think this is fine for future uses. Produces pleasing
             visual transition. Symmetry should be good for all cases
  TabAtkins: Propose to resolve to use the log. Other thoughts we can
             go back to the issue

  astearns: Additional comments?
  <florian> sounds good to me
  astearns: Proposal: Interpolate ratios using logarithm

  RESOLVED: Interpolate ratios using logarithm

CSS Contain
===========

Proposal: content-visibility: hidden-matchable
----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5595

  jarhar: I proposed this property which allows UA to search for text
          inside hidden content which find in page and scroll to text
  jarhar: Looking for resolution on 3 points. 1) is the general idea
          good? 2) is using content-visibility a good idea? 3) does it
          make sense for script to be responsible to reveal or the
          browsers?

  jarhar: Starting with 1 does it sound like a good idea?
  TabAtkins: Yes, I like the feature. We should pursue something
  astearns: Anyone with opposite opinion?
  smfr: Do we think authors can make rational decisions about to use
        hidden-matchable vs hidden? Is there a case where they would
        not want find in page behavior?
  chrishtr: Yes, one example is when you want to hide content which
            does not make sense for user. Your site has tabbed content
            and it's a previous view. Not in your current route so
            doesn't make sense to search
  smfr: Makes sense
  smfr: I think it's reasonable feature. Seems special-case-y, I don't
        really like it
  Rossen: What was the use case?
  jarhar: Use case if the user searches for something with find in
          page. Page has hidden content like mobile wikipedia where
          there's collapsed sections. User wants to find text inside
          the collapsed. Page should be able to show the sections in
          response to the search
  TabAtkins: One use case for content-visibility is let page spam a
             bunch of content into the dom and this allows the dom
             content to be searchable even if not displayed
  astearns: Rossen is that enough of an answer?
  Rossen: Thank you

  heycam: I don't have a strong opinion. Seems reasonable. I think we
          need to have some way to expose hidden content for
          searching. I wonder if some better names could be used.
          Seems clearly 2 use cases. Some content that's hidden away
          and not part of current presentation but there's some
          content hidden for virtual scrolling. Wonder if better names
          might help authors to use the right one. No specific
          suggestions

  smfr: On a previous call I mentioned things in browsers that index
        content of web pages. Scroll to and find text isn't the only
        things that care. Browsers will index for selecting later.
        Somewhat concerned about a11y. Content must not be accessible
        to things such as tab order. Weird if you can find the content
        since there's a result in there if you're using voice over do
        you instantiate the content when voice over goes there or are
        they hidden?
  jarhar: I see the tab order point.
  jarhar: I'm not very familiar with voice over or indexing pages for
          later use within browser features
  TabAtkins: Tab order is intentional. Tabbing the auto-expended
             sections open. Good a11y is the thing that expands the
             section should be tabbable. Don't know you should be able
             to tab in
  vmpstr: No use case where the only way to find content is via find
          in page. You can expand with tab or click. This is expanding
          to find via find in page. No case where only way to find it
          is find in page
  chrishtr: For a11y doesn't make sense to expose to default order
            just like doesn't make sense for tabbing because you're
            tabbing through what's seen right now. Would be good to
            expose find in page to cause hidden content to be shown
            when you search it

  fantasai: Based on the use cases I think behavior of keeping out of
            tab order makes sense. I think targeting element using
            fragment ID should be similar to find in page. Possibly
            some other API
  chrishtr: You mean fragment navigation?
  fantasai: Yeah
  jarhar: We were thinking of that earlier but got complicated when we
          implemented async flow where we make browser wait to scroll
          for two request animation frames so we give the page time to
          reveal the element before browser scrolls. Couldn't do the
          same thing for element fragment ID scrolling because page
          can observe synchronous change so we would need to not
          include the async step or break the current behavior
  jarhar: Considering the page can see changes to fragment ID seemed
          like we could not fire before match on fragment IDs
  fantasai: But then page needs to know if it's a dependent. If you
            look at use case with collapsible sections you want them
            to auto-expend even if someone gave you a link into the
            subsection. That shouldn't be worse than a text fragment
            ID. The fact that the sub-section has an ID is a good
            thing and we shouldn't treat it as less convenient.
            Shouldn't make the author do extra work to support that
  jarhar: Makes sense.
  jarhar: Wondering about separating navigating to and script showing
          it. Not sure right now on the best path forward

  astearns: We're at time. Answer I'm hearing to the first question is
            yes it's a good idea but not just for the things you have
            defined. Good to flush out other ways of navigate to other
            hidden places
  smfr: Would like an explicit request for a11y input

  astearns: I'll cut it off there
  astearns: Thanks everybody for calling in and we'll talk next week
Received on Thursday, 5 November 2020 02:39:07 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 5 November 2020 02:39:08 UTC