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

[CSSWG] Minutes Telecon 2022-11-16 [mediaqueries-5] [css-contain] [css-sizing] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 16 Nov 2022 19:51:30 -0500
Message-ID: <CADhPm3sm8nmZL=_-wSLZNoXp2T1omuQwUcKzGmZnzqNrwxm6Qw@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.


  - The group will meet next week. November 30 will be a longer meeting.
  - plinss gave an update on the server work done to add stability and
      what is left to do.

Media Queries

  - There is still discussion necessary on issue #7306 (Move the
      definition of "display mode" back to Manifest spec) about if this
      should be generalized before a resolution can be reached.

CSS Contain & Sizing

  - RESOLVED: Take second solution for this case. Update the last
              remembered size if element doesn't skip its contents
              (Issue #7807: content-visibility: auto kinda broken by
              not using last remembered size with contain: size)

CSS Values

  - Issue #3320 (Clarify fragment URLs resolve against the current
      tree, not document tree) needs more discussion about the
      motivation behind the behavior before a resolution can be reached.
  - RESOLVED: Add this definition to values-4 and evaluate new
              definition against existing test suite (Issue #5210:
              Define when border rounding happens, and to which
              properties it applies)

CSS Contain

  - There was disagreement on the value changing fragmentation as
      proposed in issue #5648 (contain:size shouldn't fragment as
      monolithic) as well as how common the use case will be once
      container queries are more common. Discussion will continue on


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0007.html

  Adam Argyle
  Rossen Atanassov
  David Baron
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Paul Grenier
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Chris Lilley
  Peter Linss
  Morgan Reschenberg
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne
  Lea Verou
  Eric Willigers

  Tab Atkins
  Yehonatan Daniv
  Vladimir Levin
  Eric Meyer
  Khushal Sagar
  Bramus Van Damme

Chair: astearns

Scribe: dandclark


  astearns: We will have a meeting next week. We'll see how many people
            we get. We'll figure out an agenda to fit the people there.
            Regular call next week, longer call at end of month.
  astearns: We're skipping #12 due to lack of people on the call.

  Rossen: If you have agenda items to be part of long call, please mark
          them. At this point we have ~60 issues. Won't be able to
          cover all. So mark issues that are a must to cover.
  astearns: So please help figure out what is a must-cover for the long
  Rossen: We have 3 agenda f2f topics that are leftovers from the past.
          Please go ahead and add Agenda+ F2F

Media Queries

Move the definition of "display mode" back to Manifest spec
  github: https://github.com/w3c/csswg-drafts/issues/7306

  ericwilligers: The motivation is the webapps wg will be writing
                 definitions for more display modes. Makes sense for
                 them to vote on modes and their positions.
  ericwilligers: uncontroversial in webapps wg
  florian: There's editorial and substantive aspects to this.
           Substantive aspect is that while most display modes are only
           invoke-able by app manifest, there's at least one that I'm
           not sure if should be. that's fullscreen.
  florian: If you invoke UI to switch viewport to full screen, should
           this be recognized as full screen?
  florian: When you're in full-screen mode, you're in full-screen mode
           regardless of how you got there. If you want full-screen
           mode to be strictly about the manifest, can do what was
  florian: But if you want media queries to be generalized, we can move
           the bulk of what's here to the spec but might need to leave
           a bit behind in media queries.
  <tantek> +1 I think I'm agreeing with florian, which is to keep the
           more abstract (non-manifest-specific) definitions in MQ5
  Ericwilligers: Manifest might say fullscreen but you're not in that
                 mode at the moment ??? This would be similar to
                 standalone. I think uncontroversial that if you start
                 in browser and go to fullscreen, it should go to
                 fullscreen. Don't think there's a problem. Distinction
                 between what manifest says and what the browser's
  florian: Two nuances, we agree on first but not sure on second. If
           you have manifest but mode isn't active, what counts is
           what's actually active. If you don't have manifest, and you
           put browser in full-screen, I think you're saying you agree
           full screen mode should apply. We agree. But PR to put it
           back to the web manifest spec doesn't agree.

  ericwilligers: We can quickly resolve this afterward, test what the
                 browsers do.
  florian: Do we want to generalize this to be more applicable broadly?
  <tantek> +1 worth generalizing
  florian: If we accept PR as is, applies to web manifest only, but
           it's worth generalizing
  ericwilligers: I don't see any problems
  florian: We need some things in both specs. IF only need this to
           apply to webapp manifest, almost everything should move
           there. Only need cross-referencing.
  florain: To apply more broadly, need some definition in media queries.

  astearns: Do we resolve to accept PR now?
  astearns: ...and then track remaining work in this issue or another?
            Or not accept PR yet?
  ericwilligers: Resolve to have remainder here
  florian: Not sure, e.g. definition of display-mode itself. If this
           notion is broadly applicable, not sure if should move.
  rossen: This conversation suggests this isn't ready to merge. Close
          but not quite. Take this extra time with florian and come
          back when it's ready?
  ericwilligers: I guess we can do that
  <tantek> +1 Rossen. Iterate on the PR and re-review next week?
  astearns: Take the time to hammer it out and we'll take it up again

CSS Contain & Sizing

content-visibility: auto kinda broken by not using last remembered
    size with contain: size
  github: https://github.com/w3c/csswg-drafts/issues/7807

  oriol: content visibility: auto, elements either enter screen or get
         out of the screen, can loose size containment, which changes
  oriol: Problem if you have scrollbar
  oriol: Changing size of elements can change scrollbar thumb size.
         Added ???-auto. Stabilizes content-visibility: auto
  oriol: ... is triggering non-stable behavior. Have example in issue. <
         describes example in the issue>. Basically as elements gets in
         or out of the screen, is switching between 100-115 pixels.
         Getting instability when should be stable.
  oriol: So 2 possible solutions. 1st is changing requirement for using
         last remembered size. Now checking element is skipping
         contents. Instead check content visibility but still check
         size containment.
  oriol: If content-visibility: auto ??? would still be able to use
         last remembered size. 2nd possibility is changing requirement
         for using last remembered size.
  oriol: ???? So if the element is skipping contents, use last remember
         size. If not skipping contents, update last remembered size.
  oriol: Vlad likes both but leans towards second.
  oriol: I don't have strong opinion between the 2.
  oriol: Anyone else have 3rd possibility to propose?
  florian: I agree 2nd is the better one. But thinking longer may have
           different opinion.
  astearns: proposed resolution: take second solution for this case.
            Update last remembered size if element doesn't skip its

  RESOLVED: Take second solution for this case. Update the last
            remembered size if element doesn't skip its contents.

CSS Values

Clarify fragment URLs resolve against the current tree, not
    document tree
  github: https://github.com/w3c/csswg-drafts/issues/3320

  fantasai: Short version of problem is there was resolution to change
            how fragment urls are handled when fragment url is changed.
  fantasai: e.g. using <base href>. But most implementations don't
            follow that, so not sure if we want to keep. Need
            implementers to review.
  fantasai: Different engines doing different things.
  emilio: I think what FF and Blink do is consistent with other things.
          Like other specs, SVG and stuff that should behave
          consistently for base URI case.
  emilio: Whatever we do should also check...is the WebKit behavior
          consistent here?
  <tantek> +1 emilio, what FF + Blink do seems both consistent and
           interoperable, can we resolve on that being what we want?

  <fantasai> https://www.w3.org/TR/css-values-4/#local-urls
  fantasai: Pasted link to what spec currently says.
  fantasai: I'm not convinced this is what we want to do, and it's
            certainly not what's implemented.
  emilio: Resolving against node tree is a bit undefined I think. Also
          I'm pretty sure we don't use StyleSheet owner node.
  emilio: I suspect blink does the same, so it's tricky
  emilio: I guess that's the intention for ShadowDOM.
  * fantasai thinks the example is particularly illustrative

  tantek: I would flip question around. Are there objections/problems
          from web dev perspective to how it's implemented? If there
          are no problems, makes sense to resolve and move forward.
          Spec is behind, fix the spec accordingly.
  fantasai: This is a change from L3 that was requested. Not convinced
            this is what we need to do.
  tantek: I mean behind reality. This has happened before.
  <fantasai> I would say it differs from reality, it's not *behind*

  astearns: So the question is should resolve fragment against node
            tree or current tree?
  emilio: The tree we're resolving against, is it correct? And are base
          URIs taken into account? I think they should be, agree with
          fantasai that it's weird they're not.
  emilio: There's also trickiness in shadowDOM behavior.
  emilio: Not sure we match with spec here.
  astearns: I assume motivating bit is what we do with shadowDOM, given
            linked issues.
  astearns: Don't know enough about this to have good idea of what
            direction to take.
  fantasai: Might make sense to kick to f2f

  tantek: To decide, is the methodology. Define from 1st principles or
          based on interoperable implementation behaviors. I'm OK with
          either approach but that's high level question to settle
  astearns: Closing to take back up in a couple weeks. I will ping
            ryosuke to try to get more details.


  plinss: We got funding to do server work. Old server is quite old,
          debian release 3 major releases back. Building new server and
          migrating rather than update old.
  plinss: New server has the fundamental infra. That's been migrated
          over. Migrated SQL DB which was what kept falling over.
  plinss: Running old software but running DB from new server. Haven't
          had issues since doing that. Also fixed bugs causing
          background processes to crash
  plinss: So stable now, but performance not great. Getting hit by
          webcrawlers. Work there is to switch draft server over.
  plinss: Fun problem is that there's lots of interdependent services,
          hard to move some but not all.
  plinss: They're on python2, PHP5, need to be updated
  <fantasai> strong +1 to serving flat files

  fantasai: I made updates to inline layout that haven't shown up. When
            do we expect it to catchup?
  plinss: Didn't know it was behind, looking, I see an issue. It'll
          start generating now.

  chris: Thanks for that work. Downtime is much less now. My question
         is bout test suite, also hosted there. That's a separate piece
         of work?
  plinss: Yes. Current funding covers server upgrade and porting python
          2-3, ???, mercurial to git update. Don't have budget for
          updating tests.
  plinss: Can take simple bugs, but don't have current funding to
          rebuild test build system etc
  plinss: Everything we have will be migrated though
  chris: For some specs, results out of date for 2 years. Any modified
         since then are incorrect.
  chris: Is that something could expect to be fixed?
  plinss: All fixable but depends on the problem. Are problems will
          build system not running to completion I'll look at. Depends
          on if this is simple bugfix or something more fundamental.
  chris: So we'll look for future update when you're done

  plinss: We have a gitea and drone server. If you want more control
          than github offers, or CI that github doesn't offer, we have
          that available now.
  florian: The calendar file is unreliably available. Sometimes you get
           500 error. Aware of that?
  plinss: Not aware, send me a note. Not hosted as current infra.
          Calendar is hosted from w3ctag.org server.

CSS Values

Define when border rounding happens, and to which properties it applies
  github: https://github.com/w3c/csswg-drafts/issues/5210

  <fantasai> ->
  dbaron: There have been differences in how border rounding works
          between impls.
  dbaron: Traian landed change to make Chromium match webkit, gecko.
  dbaron: we think border-rounding is interop now.
  dbaron: given this, and that there's dependency on it which may
          increase, we should spec it.
  dbaron: emilio opened this 2+ years ago, does he have anything to add?
  emilio: <missed>
  dbaron: In last comment I attempted to write definition in spec
          language. Other folks from other engines should look. If
          we're ok with it, lets move forward and try to spec it.
  emilio: I was misreading, I think that definition is correct.

  astearns: This is matching existing tests?
  dbaron: Yes there are various tests. I think there are a bunch of wpt
          tests for this behavior.
  dbaron: I know when Traian was making chromium changes, making
          changes caused Chromium to fail some existing tests.
          Encouraged him to test only interoperable behavior.

  asterns: Proposed resolution: Add this definition to spec and
           evaluate new definition against existing test suite.
  fantasai: Propose to add to values-4
  dbaron: <missed> I don't strongly about which spec, I leave to
  asterns: Proposed resolution: Add this definition to values-4 and
           evaluate new definition against existing test suite.

  RESOLVED: Add this definition to values-4 and evaluate new definition
            against existing test suite.

  <dbaron> (and the issue should have links to the WPT PR)

CSS Contain

contain:size shouldn't fragment as monolithic
  github: https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240067326

  florian: Situation is size containment has requirements about
           fragmentation we need to satisfy for it to work.
  florian: Reused frag. of monolithic elements because if fulfilled
           reqs but it does more. Solves problem but with unnecessary
           side effects. Can we relax solution to solve problem without
           side effects?
  florian: Size containment requires size of element doesn't change
           when content changes, and if element is fragmented, size of
           fragments don't change
  florian: Could have first without second if move fragmentation point
  florian: By saying size-contained element is monolithic, do get that
  florian: Slice the element <missed> and that solves the problem.
  florian: If the element contains content, maybe interesting in some
           scenarios the boxes themselves to that but the content is
           allowed to fragment in fixed-size fragments.
  florian: If have 3 lines of text in element and frag point is in
           middle of second line, take the entirety of second line and
           put it in next fragment
  florian: 2nd and 3rd line could fit in second fragment without
  <dbaron> sounds a lot like printing on paper
  florian: Could be interesting to allow browser to either slice or
           allow content, but allow fragmentation within these sizes.
  florian: Should we do this? I don't think any browser does now.
  florian: But could be interesting to allow them to
  <iank> I slightly prefer leaving as is

  iank: The way that balancing works is that it does need to know about
        contents and where you slice
  iank: and that has dependency on height. Also engines don't implement
        fragmentation primitives well. Hesitant about adding another
  iank: especially for such a narrow use case
  iank: So prefer leaving it

  miriam: As container queries becomes more popular, how much of an
          edge case [connection lost]

  iank: This is only needed when got full size containment or
        containment in block axis
  iank: Not needed in inline axis, which is dominant case for container
  florian: I think that's true, haven't thought about it a lot
  florian: way I was proposing to address was to invent something to
           size the content the same; don't require but allow normal
  florian: It's just an allowance, don't have to take it
  florian: Theoretically it would be fine. But only worth speccing if
           there's interest in pursuing it.
  florian: Another solution is to defer it and look again in 5 years
  florian: Not time sensitive since it's an allowance only anyway
  iank: Don't have immediate interest. Prefer leaving as monolithic at
        the moment. Can change later if there's demand.
  iank: There's demand for strongly making elements monolithic.
  iank: Which capability doesn't exist now.
  iank: There are cases where break inside avoid <missed>. I can raise
        separate issue about that

  florian: My sense is for this issue, defer it long term. Nothing
           wrong with proposed solution but no point if no one wants to
           do it.
  florian: Can close issue, or mark deferred.
  fantasai: If want to allow in future, should put it in spec,
            otherwise people won't know we considered it.
  fantasai: If think it's bad idea, should close no change
  iank: Not sure if good or bad idea. It's ehhh.
  <tantek> do we already link to it in-context in the spec as an open
           issue? so implementers can be more aware of it?
  fantasai: People make web page, use containment stuff. Then try to
            print the doc. Do we think it's best to cut lines in half?
  fantasai: I expect contain to be used all over the place. So
            significant amount of printed content will be cut in half.

  iank: Disagree with premise. Inline size containment will be used
        heavily, but full size containment not that prevalent.
  <chris> Haven't seen bisected lines of text on printing since, like,
          Netscape 2 or something
  astearns: Out of time. Will leave issue and keep discussing.
Received on Thursday, 17 November 2022 00:52:33 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC