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

[CSSWG] Minutes Telecon 2022-02-23 [css-scroll-snap] [css-tables] [css-text] [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Feb 2022 18:54:24 -0500
Message-ID: <CADhPm3vOaBsgZfEv3vF7o0_ao7i-Fkcqcpm7BSg2J7w69-eLtA@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.
=========================================


Scroll Snap
-----------

  - RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event
              model, with Adam Argyle as additional editor (Issue
              #6985: Proposing `:snapped`: exposing private snapped
              item browser state for developers and designers)

CSS Tables
----------

  - RESOLVED: Accept current Tables 3 spec text regarding calculation
              of shared borders in collapsed-border mode between table
              and cells (Issue #6230: Collapsed table first row width
              quirk)

CSS Text
--------

  - The group will check for other compat concerns and look further
      into if Firefox would consider instead making NULL U+0000 visible
      and then resolve based on that discovery (Pull Request #6983: The
      web de-facto requires NULL U+0000 to not be visible)

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

  - RESOLVED: Close no change (Issue #6376: Bikeshed the container
              property & at-rule names to avoid confusion with other
              usage of contain/container)
  - RESOLVED: Restrict container-name to just idents (Issue #6405:
              container-name string vs ident)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0010.html

Present:
  Adam Argyle
  Rossen Atanassov
  David Baron
  Tab Atkins Bittner
  Oriol Brufau
  Emilio Cobos Álvarez
  Elika Etemad
  Robert Flack
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dean Jackson
  Jonathan Kew
  Una Kravets
  Vladimir Levin
  Daniel Libby
  Rune Lillesveen
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Eric Meyer
  François Remy
  Morgan Reschenberg
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Regrets:
  Rachel Andrew
  Chris Lilley
  Lea Verou

Scribe: TabAtkins
Scribe's scribe: fantasai

Scroll Snap
===========

Proposing `:snapped`: exposing private snapped item browser state for
    developers and designers
---------------------------------------------------------------------
  GitHub: https://github.com/w3c/csswg-drafts/issues/6985

  argyle: Explainer in the issue
  argyle: Hacks and intense work with IntersectionObserver to figure
          out what element is snapped to.
  argyle: Especially with snapping being a 2-d thing, where it can be
          snapped to two elements
  argyle: And multiple elements could overlap, any of which could be
          the snappee
  argyle: This proposal attempts to deal with layout-dependency issues
  argyle: And lets the user know if there is a snapped element
  argyle: Biggest gotcha is that if you have a scroller that's shrink
          wrapped so items don't have padding, not every item might be
          snappable
  argyle: So this isn't necessarily useful for selection
  argyle: Example, header tabs in a scroller, and whichever is snapped
          to determines the contents of the tab
  argyle: Right now people go to JS that does synthetic scrolling and
          snapping to do things like this
  argyle: So this brings the functionality into CSS.
  argyle: The explainer addresses the previous issue; using
          scroll-padding can enable all elements to be snapped
  argyle: Second biggest issue is avoiding the :hover issue, where
          something can "jiggle" matching
  argyle: CSS has "loose" and "tight" loops, whether it goes out to
          user interaction or cycles within the style engine
  argyle: The explainer defines how to have :snapped be a loose loop
          like :hover, once per frame
  argyle: And it would only be able to infinite-loop during user
          interaction; it wouldn't be able to jiggle on its own while
          the page is at rest
  argyle: So devs *could* apply styles to make something snap/unsnap
          rapidly while the user is interacting, but that's it, and it
          should hopefully be very obvious
  argyle: So our hope is that we can take the good success of :hover
          and apply it over to :snapped, letting users do snapping
          control without JS.
  argyle: Maybe flackr or TabAtkins can talk about the loop prevention.

  florian: I'm convinced there's a giant use-case. Not too worried
           about the first problem, about things not being reachable by
           snapping.
  florian: Am bothered by the second situation. In proximity it's fine,
           but in mandatory I'm a little concerned...
  florian: I've not yet convinced myself you can apply the :hover
           workaround while maintaining the invariant of mandatory
           snapping.
  florian: That is, that while restyling you must resnap.
  florian: You can probably limit it to once per frame, but you'd have
           jiggling at rest, or you'd violate the mandatory requirement
           and not be snapped at some times.
  florian: So my question is if we *need* to solve the problem this
           way? Would it be simpler to have snapping events that fire
           when snapping to something?
  florian: You'd still have loops if your JS did silly things, but
           that's much wider.
  <fantasai> +1 to JS events
  <argyle> https://github.com/argyleink/ScrollSnapExplainers
  argyle: Some JS events talked about in the explainer; those are part
          of the proposal. snapChanged, snapChanging events, and
          snapTo() function
  argyle: So yeah, JS definitely important.
  <fantasai> That issue's been open for awhile and needs help
             https://github.com/w3c/csswg-drafts/issues/156
  argyle: "changing" triggered when you've passed a threshold to start
          switching to a new snap target
  florian: My question is if it's *sufficient* to have events, rather
           than just the pseudo?
  argyle: There's a lot of cases where the CSS visual feedback is just
          as important to JS knowing the snapped items.
  argyle: I've got an example that adds a huge gap for one frame to
          detect the snappee... the timing isn't right. We're trying to
          give CSS visibility into the inner state.
  argyle: I don't think we could use just a JS solution. But I do think
          there's a competitive proposal in Style Queries.
  argyle: So style queries might be able to pacify this use-case.
  <TabAtkins> (I don't think they could; snapping isn't exposed in CSS
              state except via side-channels of properties being
              applied.)

  flackr: I think we have similar problems with :hover, and :hover
          state doesn't update until you move your cursor, we could do
          a similar thing for :snapped, so even if snap changes we
          wouldn't update the :snapped until user input occurs
  flackr: We think in most cases devs wouldn't create these cycles,
          because they usually don't with :hover
  flackr: We'll have to make sure we have the same snapped element,
          that does get tricky.
  flackr: I think there are some cases that - say you have snapping in
          both directions, you probably want the element snapped in
          both directions to get the pseudo rather than first in dom
          order, there's some tricky cases we'll need to make sure of
  smfr: Your primary reasons to want sounded like something appropriate
        for script - knowing what element was selected.
  smfr: Wonder if you considered exposing on the scroller itself a list
        of snapped elements.
  smfr: Like .scrollLeft, etc, could have .snappedElements
  smfr: Would change on scroll events
  argyle: Like that idea, kinda goes with the scrollTo() options for
          snapping
  argyle: JS should be able to get the list of snappable children.
          Sounds like a good idea
  florian: There is indeed a similar to :hover when we talk about
           proximity.
  florian: But there is not in proximity a strong expectation you're
           always snapped to something. If we break a loop, that's
           fine.
  florian: With mandatory you're required to always be snapped to
           something. Always - authors can depend on this.
  florian: There's never an unsnapped state.
  florian: Not just scrolling can trigger this, restyling or animation
           can change the position of the snapped element.
  florian: If we have a clean way to make this continue being true,
           great
  florian: But I don't see a sufficient explanation in the explainer to
           be clear on this.
  florian: If it's impossible, oh well, we'll figure it out. Worry is
           that it's possible, just very hard to do and maybe
           non-interoperable so the invariant is broken in different
           ways
  <argyle> looks like as part of the event data on the js events
           snapChanged and snapChanging, I've added snappedList and
           snappedTargetsList which provide arrays of snap children on
           axes
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged#:~:text=SnapEvent.snappedList
           I do still think there's room for a generic api into this
           tho!
  flackr: I think the first proposal I presented does let you maintain
          mandatory snapping
  flackr: Your snapped state changes the style, which might cause you
          to snap to another target, but your :snapped won't reflect
          that until the next frame
  TabAtkins: Underneath the covers, mandatory snapping invariant is
             maintained, but not seen on every frame

  <fantasai> https://github.com/w3c/csswg-drafts/issues/156
  fantasai: Wanted to point people to discussion about event model,
            been open for a long time
  fantasai: I think this pseudo-class would be great, and event model
            should be available at the same time or before the pseudo.
  astearns: Agree, not against the pseudo, but think the events are the
            more important thing
  astearns: Could even wait on the pseudo until we notice the events
            are often being used to add a class
  <argyle> event `snapChanging`
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanging
  <argyle> event `snapChanged`
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged
  fantasai: I'd also like to see the situation with mandatory snapping
            and overlarge elements fixed first; it makes content
            inaccessible if done wrong.

  astearns: Any other comments? Concerns?
  astearns: So it sounds like you have a lot of feedback.
  argyle: The events should be well-defined, but I haven't taken up WG
          time yet. Are they appropriate here?
  fantasai: Yes, they'll be specced in this group.
  fantasai: Probably in Scroll Snap 2.
  TabAtkins: Sounded like people interested in adding to Scroll Snap 2,
             should we resolve to start that spec with this in it?
  astearns: Any objections?
  fantasai: We should resolve to start an ED and include both :snapped
            and the events
  florian: If there's a different event model drafted in an issue,
           should probably decide
  fantasai: Can put both in for now and figure it out
  astearns: So proposal is to have Scroll Snap 2 ED with pseudo-class
            and event models, with Adam as editor?
  florian: Think we should have both so it doesn't get frozen in
           without discussion
  argyle: I'll be checking soon how the two proposals compare
  astearns: Objections? Anyone need more time?

  RESOLVED: Start Scroll Snap 2 ED, with :snapped and snapping event
            model, with Adam Argyle as additional editor

CSS Tables
==========

Collapsed table first row width quirk
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6230

  fremy: While reimplementing tables in chrome, the dev found a lot of
         bugs that weren't bugs per spec, but were unexpected by
         authors
  fremy: We realized the new version of the spec was causing the issues
  fremy: But behavior that is currently implemented was mentioned in an
         old version of the spec
  fremy: So chrome dev decided to implement the old behavior, since we
         didn't have resolution for the spec change, but they'd like to
         change to the new behavior because the old didn't make much
         sense
  fremy: They feared there would be some breakage with new behavior, so
         they added a UseCounter and studied websites
  fremy: Found that on all websites, the changes to layout would be
         very small, if any, and often slightly better. Found one case
         where it was slightly worse, but in no case was it worse than
         about 3px.
  <bradk> 3px narrower or 3px wider?
  fremy: So they want to update their impl to the new spec, if the WG
         approves it
  <iank> https://www.w3.org/TR/CSS2/tables.html#:~:text=17.6.2-,The%20collapsing%20border%20model,-In%20the%20collapsing
  <astearns> https://www.w3.org/TR/CSS2/tables.html#collapsing-borders
             is a more interoperable version of iank's URL
  fremy: So that's context. Here's the behavior.
  fremy: When you have a table in collapsed border mode
  fremy: Two cells next to each other, the border needs to be
         "harmonized" - pick one of the two borders and draw.
  fremy: Must also harmonize border between cells and the table itself.
  fremy: In the new spec you harmonize all the cells on the table edge,
         take the biggest one. Do that for each edge.
  fremy: The older spec for some reason only harmonized the first cell
         of the first row.
  fremy: If you have a table you don't draw borders around the header
         row, but you use borders for the rest,
  fremy: According to the old spec, the borders will then be drawn
         outside the table
  fremy: so it often just causes an overflow of like 1px, not
         noticeable
  fremy: But scrollbars can pop
  fremy: And devs can't figure out why it's happening
  <bradk> That answers my question

  fremy: Bug is marked as Doesn't Reproduce in Firefox, technically
         true, because they do something differently but still wrong,
         it's based on rounding.
  fremy: So proposal is to accept the new spec text: when you decide
         the border of a table, you look at *all* the cells against
         each border edge, not just the first
  fremy: Should be more in line with dev expectations, but it's
         currently a breaking change so we wanted a resolution.
  iank: Ironically this is one of the better specified areas in 2.1
        regarding tables, which is why everyone has the same (bad)
        behavior.

  fantasai: I worked on this issue in 2.1. I was really unhappy with
            the old resolution.
  fantasai: Happy to move away from that.
  fantasai: There was a proposal to have the borders not belonging to
            the table overflow; another was to count them as part of
            the border with. I think there was a third to allow it to
            overlap with the margin, but take up space if there wasn't
            enough margin.
  fantasai: Say you have a table with narrow borders, and you used a
            thick border to highlight an interesting cell.
  fantasai: If you want the table to stay centered when the highlighted
            cell happens to be on the edge, we can't include the
            difference in the border width, it'll shift the table
            slightly
  fantasai: But that is a more complicated behavior, but I want to put
            it out for consideration.
  fantasai: That effect is why, I suspect, why we had not taken the max
            border width, so those borders could overlap into the
            margin.
  iank: I don't believe we've found anyone using it that way. Might
        exist, but broadly the usage fell into a few buckets.
  iank: Primary is calendar widgets - craigslist was the big one. Had
        some dead code to add a transparent border to fix the behavior.
  astearns: So the current spec describes what you prefer?
  iank: I think the max-border behavior is defined in Tables 3.
  iank: caveat-ed on us not breaking too much
  iank: Use counter is high-ish but layout changes are very minor.
  fremy: Current Tables spec does have symmetrical behavior

  astearns: fremy, do you have opinions on the behavior fantasai
            described?
  fremy: I see it's useful behavior
  fremy: But think you should probably be using outline to add this
         kind of call-out border
  fremy: So I think the simple behavior is fine. Wouldn't be mad either
         way.
  fantasai: Think it's probably fine.
  <fantasai> The thing I *wish* we could fix in table borders model is
             to invert the priority so that table wins over rowgroup
             over row over cell.
  <fantasai> The current version is just so impossible to deal with if
             you want different colored but same-thickness borders for
             rows vs rowgroups, etc.

  astearns: So proposed resolution is no change to the Tables spec,
            just confirming that the current spec is intended.
  iank: Think the spec fixes some unintuitive behavior for webdevs.
        Will report if there's problems.

  RESOLVED: Accept current Tables 3 spec text regarding calculation of
            shared borders in collapsed-border mode between table and
            cells.

CSS Text
========

The web de-facto requires NULL U+0000 to not be visible
-------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/pull/6983

  florian: It's simple. Currently specs require every control character
           to be made visible. It turns out it's not web-compatible to
           make NULL visible. He requests we add this to the list of
           characters that can be invisible.
  florian: Chrome and Firefox currently do that anyway.
  <PeterC> What's the spec text that this proposal would impact?
  florian: So to the extent that's true, I'd agree.
  * fantasai thinks it needs to also clarify that this character would
             therefore be invisible, but that can be a follow-up edit

  jfkthame: I'd like to see content that was affected; there doesn't
            appear to be examples in the webkit bug
  smfr: Looks like it affected iCloud Notes
  smfr: Not sure why a null character got in there
  jfkthame: It's not something we've discussed in Firefox, but I'd
            personally entertain making it visible in FF.
  jfkthame: Wonder if apply can't just fix iCloud if there's a problem
            there
  jfkthame: stray control characters in content are generally a bad
            thing; even worse if people can't tell they're there
  astearns: That's why we had the resolution to make things visible
  astearns: Has FF tried to make the other control characters visible?
  jfkthame: My recollection is we do at least on pre-release channels;
            unsure if we've turned it on in release. Think we've had
            trouble getting other browsers to line up.

  astearns: Anyone from Blink have comments?
  iank: Will have to check with koji.
  florian: I think there was a point in Blink where they were visible
           if there was a visible glyph in the font for them, but as
           that's generally not the case, they were still invisible.
           Not sure if that got fixed.
  astearns: I suggest we loop in koji or whoever else in Blink;
            jfkthame please check the state of the visible-chars code
            in Firefox; we'll see if there are any other compat
            concerns besides iCloud notes.
  astearns: And we'll come back to this on a later call.

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

Bikeshed the container property & at-rule names to avoid confusion
    with other usage of contain/container
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6376

  astearns: Sounds like you'd like to change this issue no-change?
  miriam: Yes, I'd love that.
  astearns: This feature has gone thru lots of people. Haven't heard
            complaints about the current names.
  astearns: Anyone object to closing this no change?
  <jensimmons> +1 to closing
  <fantasai> +1
  astearns: Or has anyone heard complaints?

  RESOLVED: Close no change

container-name string vs ident
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6405

  miriam: In the current spec we allow container names to be either a
          string or an ident.
  miriam: Advantage of string is you can use attr() to take from the
          element and use it for a container name.
  miriam: That could also be possible if browsers implement the
          extensions to attr() that let you specify the type, attr(foo
          ident)
  miriam: Florian suggested just accepting ident would be easier
  miriam: Don't have a strong opinion here. Like the flexibility, but
          would like browsers to implement attr() stuff
  fantasai: Currently attr() is not only restricted to strings, but
            also just to the content property, so it'll require
            extensions regardless.
  fantasai: So I think we can keep it ident-only, and when we extend
            attr() we can make sure it allows for idents as well.
  <bkardell> kinda +1 to that
  astearns: Not sure it follows we'd get attr() in this property and
            with 'ident' behavior at same time, but I suppose we'd have
            to either change attr() or change this property to allow
            strings.
  bkardell: +1 to fantasai about starting with ident.
  bkardell: I think attr() is a need in lots of use-cases way beyond
            this, feels bad to make an exception to solve one case as a
            first option. It might be a thing we need to do, but it
            feels bad to start assuming that.
  TabAtkins: I think I'm the main defender of keeping string, but
             fantasai makes a good point that attr() isn't allowed
             anywhere at this point, so we'll fix it when we fix it,
             and I'm fine with ident for now

  astearns: So hearing strong arguments for restricting to ident.
            Anyone wanna argue for strings?
  astearns: Proposed resolution is to restrict to idents. We'll see if
            we need to add strings later, or if attr() is sufficient.

  RESOLVED: Restrict container-name to just idents
Received on Wednesday, 23 February 2022 23:56:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:20 UTC