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

[CSSWG] Minutes TPAC/Vancouver 2022-09-16 Part I: CSS Values, Selectors, CSS Anchor Positioning [css-values] [css-selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:59:44 -0400
Message-ID: <CADhPm3viF664j3Lfghwu6YGVLZd+4zXbvN9bw+vwoJ_QpkgjJw@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 Values

  - RESOLVED: ch units can cause a font download, no change to spec
              (Issue #3135: ch units shouldn't cause font downloads)


  - In the github discussion for issue #7422 (Add pseudo-classes for
      `<select>` being a drop-down box vs a list box) the consensus was
      generally in favor of adding a new pseudo-class.
  - During the discussion, though, there were questions about the value
      of adding a new pseudo-class that web developers will have to
      memorize vs that value of this new functionality.
  - Discussion will move back to github to draw out what the counter
      proposal of adding integer attr selectors would look like so it's
      easier to compare.

CSS Anchor Positioning

  - RESOLVED: ED of Anchor Positioning, editors TabAtkins, iank, jhey
              (Issue #7282: Introduce CSS Anchor Positioning)


Agenda: https://github.com/w3c/csswg-drafts/projects/32

  Rachel Andrew, Google
  Jake Archibald, Google
  Adam Argyle, Google
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Google
  Bert Bos, W3C
  Tantek Çelik, Mozilla
  Daniel Clark, Microsoft
  Emilio Cobos Álvarez, Mozilla
  Yehonatan Daniv, Wix.com
  Jon Davis, Apple
  Karl Dubost, Apple
  Kevin Ellis, Google
  Elika Etemad, Invited Expert
  Robert Flack, Google
  Megan Gardner, Apple
  David Grogan, Google
  Daniel Holbert, Mozilla
  Ian Kilpatrick, Google
  Una Kravets, Google
  Chris Lilley, W3C
  Alison Maher, Microsoft
  Cameron McCormick, Apple
  Eric Meyer, Igalia
  Tess O'Connor, Apple
  Olli Pettay, Mozilla
  Simon Pieters, Bocoup
  Manuel Rego, Igalia
  François Remy, Invited Expert
  Morgan Reschenberg, Mozilla
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Adobe
  Dominik Röttsches, Google
  Peter Rushforth, Natural Resources Canada
  Khushal Sagar, Google
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Fuqiao Xue, W3C

Scribe: fantasai
Scribe's scribe: emilio

CSS Values

ch units shouldn't cause font downloads
github: https://github.com/w3c/csswg-drafts/issues/3135

  astearns: We discussed this issue in NYC
  astearns: whether ch units should cause font downloads
  astearns: didn't resolve because Myles wasn't there
  astearns: but general consensus was that we would leave spec
            unchanged, meaning ch units can cause font downloads

  myles: Given the author's perspective here, they just want to make
         something e.g. 5ch wide, and the specific char isn't super
  myles: so if your font doesn't have the char, search down the list,
         but characters that are used are in the font
  myles: in order to be exactly conformant you have to download things
         that are unnecessary
  myles: They asked for ch, didn't say you have to match zero
  myles: just said "make it 5 characters wide" so I think it's the
         wrong decision

  dbaron: Idk how closely you read minutes from last time, we did talk
          through the various possibilities
  dbaron: one of the issues was, if the ch unit doesn't trigger a font
          download, then you either end up in a situation where ch unit
          might change later
  dbaron: or that it might be different whether or not downloaded a font
  dbaron: other options all have problems, too
  dbaron: so leaving as-is seemed like the least bad thing
  <florian> +1 to david
  <fantasai> +1
  astearns: Anyone else?

  astearns: To close off, would like to resolve that we are making no
            change for this issue.

  RESOLVED: ch units can cause a font download, no change to spec

  astearns: Any other details discussed not in the spec that we should
            add in?
  astearns: dbaron, you had a summary
  dbaron: I have summarized discussion, leave to editors whether any
          non-normative changes needed to clarify


Add pseudo-classes for `<select>` being a drop-down box vs a list box
github: https://github.com/w3c/csswg-drafts/issues/7422

  zcorpan: Proposed pseudo-class for <select> elements
  zcorpan: it's implemented in both Gecko and Chromium for their UA
           styles, under a vendor prefix
  zcorpan: WebKit doesn't implement the pseudo-class, instead uses
           attribute selectors
  zcorpan: and they have some bugs because of that, because hard to get
           the details right
  zcorpan: so I think there's agreement in the issue that we should
           have this pseudo-class
  zcorpan: and just need to settle the naming
  <heycam> the WebKit UA style rules:
  zcorpan: :select-with-dropdown and :select-no-dropdown

  fantasai: I haven't read the issue, was the bug in webkit about
            parsing the size attribute as int?
  zcorpan: It's parsing the size attribute correctly, the UA style
           sheet has an approximation of what the HTML results are
  zcorpan: so some edge cases will get wrong UA styles
  zcorpan: get a drop-down widget, but UA style thinks it should be a
           list box
  zcorpan: so a bit of a mismatch
  fantasai: Asking because if it's the way the UA parses integers not
            being replicate-able in css
  fantasai: maybe we want to introduce a way of selecting based on
            whether the attr is parsed correctly as an integer
  fantasai: that's been requested and more generally useful
  zcorpan: I guess it would be possible
  zcorpan: complication because HTML has multiple number attributes
  zcorpan: It has integers and signed integers and floats
  zcorpan: I guess CSS could have those as well
  zcorpan: but CSS numbers are normally parsed differently from HTML
  fantasai: We could make it the same or have a flag
  zcorpan: Still seems more difficult to use as Web developer compared
           to pseudo-class
  zcorpan: there's also the multiple attribute
  <dbaron> "The display size of a select element is the result of
           applying the rules for parsing non-negative integers to the
           value of element's size attribute, if it has one and parsing
           it is successful. If applying those rules to the attribute's
           value is not successful, or if the size attribute is absent,
           then the element's display size is 4 if the element's
           multiple content attribute is present, and 1 otherwise." is
           the relevant quote from
  <dbaron> https://html.spec.whatwg.org/multipage/#concept-select-size

  emilio: I don't think it's a bad idea, but do we really need 2
          pseudo-classes instead of one?
  emilio: Would rather have single one, they're mutual exclusive
  emilio: assuming it's <select>-specific
  emilio: using select:listbox and select:not(listbox) would be nicer
  zcorpan: I think that's an okay outcome, biggest difference is you
           need to include a type selector to match the :not() state,
           whereas with pseudo-classes can only use the pseudo-classes

  fantasai: We need to consider that we keep adding pseudo-classes
  fantasai: if we don't really need a pseudo-class
  fantasai: it's better not to have it
  fantasai: so that there's less for people to memorize
  zcorpan: Agreed
  fantasai: If we can do this with integer parsing and it's not too
            tricky maybe that's a better way around it
  <TabAtkins> In particular, if this is <select>-specific, then its
              name should be pretty <select>-specific, not generic.
              Probably means it needs a "select" in the name. But then
              it's just awkward to have to specify select again, like

  heycam: I'm not strongly against adding pseudo-classes, but wondering
          if really that useful to expose to authors
  heycam: If WebKit wants to fix compat issues, they can have an
          internal pseudo-class like other engines
  heycam: but for authors, thinking whether they are using listbox or
          dropdown, is something they know ahead of time
  heycam: I think it's rare for pages to switch between the two, so
          don't know how useful it is for authors to have different
          styles depending on this
  heycam: or need to rely on the flexibility of how HTML parses these
          attributes, vs knowing through the DOM already
  <fantasai> +1
  zcorpan: For cases where dev controls both markup and CSS, but that's
           not always the case
  zcorpan: maybe you're writing a stylesheet for a design system, want
           to apply to all WordPress pages
  zcorpan: you don't know what HTML they will use
  zcorpan: so that's why pseudo-class makes sense

  emilio: Was going to make similar comment to heycam
  emilio: We should encourage use of multiple attribute, it's easy to
          write selectors for that
  emilio: rather than relying on parsing of size attribute
  emilio: if you're making design system, ask them to use that
  emilio: but I'm on the edge on whether it's worth having a
          pseudo-class for this or not
  zcorpan: Multiple is a semantic difference
  emilio: sorry, yes, you're right
  zcorpan: You can have a listbox that's not multiple

  fantasai: Doesn't seem to me like the selector for this would be that
            difficult if we had number parsing
  fantasai: is [multiple] plus size parsing as an integer >1
  fantasai: The details of how to parse invalid size attributes is a
            concern for implementors but not authors
  zcorpan: Type out the two selectors?
  fantasai: People usually don't write junk in their size attribute
  <TabAtkins> `select[size > 1], select[multiple]`
  <emilio> `select:is([multiple], [size]:not([size="1"]))` is probably
           close enough in practice today
  <fantasai> `select:not([size>1],[multiple])`

  dbaron: One, I tend to agree that if you're building a design system,
          you probably want these sorts of things
  dbaron: I think part of the reason we don't see much demand is that
          select is so hard to style, don't run into this problem much
  dbaron: if styling select worked more reliably, they would want on
          this more
  <fremy> +1 to what dbaron just said, styling select is a pain
  dbaron: Quoted HTML, which defines the display size of a select
  dbaron: condition for a combobox vs listbox is display size being
          equal to 1 or not
  zcorpan: or multiple attribute being present or not
  dbaron: There's a few reasons the selectors above are wrong
  dbaron: one is that you need to test for size being zero
  dbaron: because HTML applies rules for non-negative integers
  dbaron: you want a valid size that is zero or 2 or more
  dbaron: or the multiple attribute
  dbaron: It's doable if you had HTML non-negative integer parsing
  dbaron: but might be worth having this pseudo-selector anyway

  TabAtkins: fantasai's point was that dealing with invalid things is
             the sort of things that UA needs to care about, but page
             author doesn't
  TabAtkins: if they're putting random trash in their size attribute,
             that's their problem
  TabAtkins: but HTML UA needs to deal with all kinds of random trash
  <heycam> +1 to if we do have a way to do this, would rather a
           specific pseudo-class rather than a general integer parsing
  dbaron: As you go further down the stack to style sheets meant to
          apply to more and more pages, get closer to needing to match
  dbaron: bootstrap might get bugs on this
  TabAtkins: Bootstrap can say, "don't write random trash in your size
             attribute and this will work correctly"
  TabAtkins: if we were stricter in parsing this earlier we wouldn't
             have this problem for UAs
  TabAtkins: but even widely-used library, nobody needs to deal with
             this much trash
  TabAtkins: put a number here, and it works. Put a non-number here and
             it'll not work
  fremy: Authors shouldn't have to read the spec to figure out the
  fremy: of course they can copy some weird code, but not very
  fremy: you will copy and paste it, but not clear what it does at
         first sight
  fremy: if already implemented in engines, have this pseudo-class
  fremy: that sounds useful so why not
  fremy: Why are we wasting time discussing if it's just removing a
         prefix in the code, seems silly
  <emilio> FWIW this is how Gecko used to implement this with attribute

  astearns: We started with what we called a pseudo-class, and now
            discussing maybe not having pseudo-class
  astearns: With arguments presented so far, anyone convinced we should
            have it?
  heycam: Me
  astearns: Should we try to resolve to add pseudo-class?
  fantasai: I'd like to hear from Rachel Andrew and emeyer
  fantasai: if they are like, "Yes, we should definitely have this!"
            then great
  fantasai: If not, I'm skeptical
  <rego> there has been a lot of research about styling select in
         openUI, does anyone know if this topic was discussed?
  emeyer: It's hard for me to say, a pseudo-class mostly feels correct
          here, but fantasai is correct, we have so many pseudo-classes
  emeyer: even more than I realized until recently
  emeyer: So I'm not sure I'm 100% convinced that it's best
  emeyer: Some way of doing this is good
  emeyer: but whether it should be a pseudo-class or ???
  fantasai: We would add number-based attribute selectors, and you
            would make a selector
  astearns: It would be a copy-paste incantation
  fantasai: Still have to do that if it's a pseudo-class!
  <emilio> Another interesting edge case is `size=""`
  <heycam> emilio, similar but not exactly the same as the current
           WebKit UA style rule selectors
  <heycam> emilio, yes that is exactly the difference

  TabAtkins: Who is asking for this? In the UA is one thing, but do
             other people need it?
  zcorpan: Reset stylesheets use it
  zcorpan: incorrectly, usually
  fantasai: They are copy-pasted, so they can write a proper selector
  zcorpan: But used in lots of pages, should get all the cases correct
  <fremy> https://github.com/sansotmon/asistencia-salvarte/blob/50dde64556294e8e42dbb2f7950f1b9c078ebef7/web/core/themes/olivero/css/components/form-select.css
  <fremy> ```[dir="ltr"] select[multiple] { padding-left: 9px }```
  <fremy> ^ this is wrong, first hit on github
  <TabAtkins> Are they getting bugs and ignoring them because parsing
              numbers via CSS is hard? Or are they just not getting
  <TabAtkins> Importantly - if they're not getting it right, *is this
              causing problems for people*?
  emilio: Empty size attribute is another case
  emilio: also slightly more efficient to do a pseudo-class
  emilio: pre-parses faster than other random attributes
  emilio: If people feel this is useful, then maybe it's not worth
          copy-pasting a weird incantation

  rachelandrew: I think in terms of being easier to explain and less
                error-prone, pseudo-class is good
  rachelandrew: but do people actually want to do this, is also a valid
  rachelandrew: if people aren't asking for it
  rachelandrew: I like things to be straightforward
  rachelandrew: but we also have a lot of pseudo-classes, and have to
                teach people
  rachelandrew: so I don't have a strong feeling, but like emeyer I'm
                on the fence
  astearns: Then what I want to do is to close off the discussion in
            this meeting, take back to issue, have whatever the actual
            correct integer and multiple check would be
  astearns: so we have something to compare
  astearns: and come back to this issue on a telecon
  zcorpan: OK
  astearns: Any other questions on this?

  fantasai: Do we want to add integer attr selectors?
  fantasai: generally speaking, do we want a proposal for that?
  astearns: I don't think we can decide that right now

  <fremy> select[multiple], select[size] { height: auto; }
  <fremy> in bootstrap

CSS Anchor Positioning
github: https://github.com/w3c/csswg-drafts/issues/7282
slides: https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0009/TPAC_2022_-_CSS_Anchoring.pdf

  TabAtkins: Presented early idea in May
  TabAtkins: continued working on it
  TabAtkins: Jhey has prepared a slide deck intro with details
  <xfq> https://jhey-presents.netlify.app/tpac-2022/
  -> https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0009/TPAC_2022_-_CSS_Anchoring.pdf

  jhey: CSS needs you! So want input on shaping where this goes
  jhey: Anchoring on the Web is a common pattern, very tricky, and
        headache for developers
  jhey: when do I do it, how do I do it?
  jhey: How to calculate the position, can I do it in an attribute
  jhey: it's used for tooltips, menus, things driven by interaction
  jhey: but the most common pattern is pop-ups, things that need to get
        into the top layer

  jhey: Thinking of a tooltip, we have a containing viewport, and then
        we have the anchor thing like a tooltip, and then the anchor
        which is a button or something
  jhey: and then have the arrow visually connecting the two
  jhey: There are workarounds using abspos, requiring a special DOM
        structure involving wrappers and relpos
  jhey: potential invalid HTML to put things inside other things
  jhey: it's hard to scale or respond to viewport changes
  jhey: might go with an example like this (shows code example)
  jhey: you could go different route without a wrapper, then need to
        work out positions
  jhey: but it's hard to maintain
  jhey: Could use JS, but then need boilerplate, and styles are leaking
        into scriptland
  jhey: then what info do you need, how to calculate offsets, etc.
  jhey: (shows code example)
  jhey: All of those solutions look the same
  jhey: user sees it looks great, but dev experience is not great
  jhey: done right this could be much better for a11y etc also

  jhey: There's issues!
  jhey: when something goes out of the viewport, if things change, how
        do we change? what about scrolling?
  jhey: Lots of edge cases
  jhey: Someone solved it?
  jhey: there was one called tether.js, another popper.js
  jhey: interactions are handled by JS, very config-heavy
  jhey: lots of things to decide on, and another dependency to maintain
  jhey: it gets the job done, but devs don't typically like adding
        extra JS files
  jhey: Another is Floating UI, less download, but is it better to use,
        still extra dependency, which to use?

  jhey: How about we keep the styles in the styles and use a new
        anchoring API?
  jhey: we have container, viewport, tooltip
  jhey: think about viewport like ocean, anchor is anchor , and chained
        to the tooltip boat
  jhey: here the browser is working out where to put it. Not enough
        room for the boat here? shift it down
  jhey: no dependencies, no wrappers
  jhey: We're experimenting and learning, I've got some demos here
  jhey: Basic anchor, this is how it looks
  jhey: no DOM structure required, can live anywhere
  jhey: here I've got two boats tethered to the same anchor
  jhey: I have an anchor name, tether to it
  jhey: passing anchor name and use whichever position I want
  jhey: I'm using calc here, can use inside calc
  jhey: and then anchor-side will get the width/height of anchor
  jhey: browser will work out the offsets as I move things around

  [What's happening slide]
  jhey: Containment works as usual, browser handles offsets for us
  jhey: different fallback positions
  jhey: if boat can't fit in the ocean here, then move it somewhere else
  jhey: UA does it for me
  jhey: use position-fallback to attach to fallback list of positions
  jhey: can change containment, is contained by viewport or something
        lower in the tree
  jhey: can clip x axis or y axis
  jhey: or both
  jhey: same demo again where constrained by scroller instead of
        allowed to leak
  jhey: Things needed are things like popups
  jhey: being able to anchor things in the top layer
  jhey: you can do this currently with JS solutions, but they do hit
        some limits with regard to resizing

  jhey: Another is <selectmenu>
  jhey: Where this gets really cool, you can do some interesting things
  jhey: we have a chart, can use anchor positions in calc() I can
        tether a tooltip to the chart
  jhey: and attach the min and maximum, and it'll work it out for me
  jhey: you can use more than one anchor in your positioning
  jhey: or anchor to highest bar or lowest bar
  jhey: can also do nested menus, holy grail of anchoring
  jhey: just anchor to something inside, and works well, menus squishes
        as viewport gets narrower

  jhey: A few open questions
  jhey: how to detect which side to put your arrow?
  jhey: how do we scope things like position-fallback

  emilio: I had a question, seen a lot of ways of when viewport
          resizes, most of the fallback is clipping or shrinking
  emilio: how easily can you do sliding fallback instead?
  emilio: when container goes out of view
  emilio: Thinking about how some native platforms and even Gecko's
          popups specify after position, and the way we do it, you have
          an anchor node and you specify the side of the anchor and the
          side of the popup you want to align
  emilio: e.g. top left top left, would put your item on the bottom by
  emilio: would give you various ways to figure out the final position
          if you don't fit
  emilio: It's not be so powerful with offsets, like the fancy chart
          anchoring was pretty cool and not sure to what extent could do
  emilio: but for anchoring to single thing, seems much easier to
          reason about vs doing all the math and fallbacks yourself
  emilio: Have you thought about that kind of API, you can specify
          where the popup goes relative to anchor?
  emilio: we allow customization with margins
  emilio: so we use the top/left margin to shift in the direction
          you're anchored
  emilio: so was wondering what kind of exploration you've done of this
          kind of space and other ways in platform
  emilio: what Gecko does is very similar to what ??? does
  emilio: I don't think Windows has a native thing

  iank: We did do a more limited version of this, anchor to a single
  iank: similar to what you're describing
  iank: We found though that yes, it covers the 60-70% case, but you
        start to lose out on some of the slightly more advanced cases
  iank: and there are cases, multiple anchoring thing, is quite useful
        for a number of use cases
  iank: [missed example]
  TabAtkins: You might want to use min/max zero or 100%
  TabAtkins: or fallback 0 or 100%
  TabAtkins: so you're anchored to the side until anchor goes off the
  TabAtkins: Right now here with the pop up terms, it's pretty awkward
             right now
  TabAtkins: Maybe these cases are simple enough to use syntax like you
  TabAtkins: but this should be a reasonable case, and not require
             hundreds of @position-fallback rules, because that's bad

  [shows content out demo]
  emilio: In your example where the container shrinks, the positioned
          elements flips from below to on top of anchor
  emilio: but in one example gets clipped instead of remaining in
  emilio: inside a container instead of viewport
  emilio: if you keep shrinking, it could be kept inside, but then leaks
  emilio: by default, authors won't test all combinations, and things
          will be offscreen in some cases
  emilio: so more declarative could allow UA could make sure that the
          positioning is on-screen
  iank: Any time that we tried to go, "ok, we want this behavior",
        there's a use case for opposite behavior
  iank: some cases do actually want it fixed
  iank: Hear your concern, but there's a plethora of use cases and all
        of them want something slightly different
  iank: similar argument could be made for testing all possible screen
        sizes, and yeah you need to test

  heycam: Thanks for presentation, a few questions
  heycam: the pop-up thing, does that always move to the top layer or
          not required?
  TabAtkins: Not required
  TabAtkins: if using popup API, moves to top layer
  TabAtkins: but otherwise treated as abspos

  iank: The containing block, you can only reference anchors within
        that containing block
  iank: So useful for components
  iank: so go to the scrolling example, here the containing block is
        inside the scroller so it stays inside
  heycam: One question is what happens when there are transforms
          between anchored thing and anchored
  iank: Similar rules, scrolling is complicated and want to talk about
        that separately
  iank: but for transforms use staticpos propagation rules, basically
        assume no transforms
  heycam: No transforms?
  emilio: Transforms make a containing block for fixed descendants
  iank: Thing that breaks is if you're transforming the anchor, that
        does break
  iank: there's a tradeoff here in that this is fundamentally a layout
  iank: so animating a transform, don't want to slow it down
  iank: there is an option to incorporate transform

  heycam: What about shadow tree and visibility of names?
  heycam: Is this another example of issues around exposing names to
          shadow trees?
  TabAtkins: Yes
  TabAtkins: Using anchor name itself isn't problematic, because it's a
             tree search
  TabAtkins: but for the fallback rule and its name, that has the same
             problems we have in other rules like @keyframes

  <Bert> (For the historians: Around 1997, Håkon and I discussed floats
         with anchors and ‘elastic bands’, to try and keep floats near
         their anchors or near each other, depending on the strength of
         the ‘elastic’. Among the goals were sidenotes and parallel
         texts, such as a text and its translation. The difficulty for
         the author to know whether to write "see on the left" or "see
         on the right" was one reason we decided to postpone that

  emeyer: Seems like a lot of the examples use a lot of calc'ing,
  emeyer: I wonder if anchor-side keywords in the draft, are those
          supposed to be ands, can they be ors?
  emeyer: so you could say something like center left?
  <florian> +1 to emeyer
  iank: A lot of these use left/right, and haven't implemented center
  iank: so many could be replaced with left center
  emeyer: So popup in the middle, wouldn't need calc?
  jhey: Could use percentages
  emeyer: So for simple things might not need calc()

  emeyer: My other question is, am I understanding that a popup can be
          placed in relation to multiple anchors?
  TabAtkins: Yes
  emeyer: So text with footnote reference in the middle, could have the
          footnote could be vertically center-aligned but have its edge
          against the column of text
  TabAtkins: Yes
  emeyer: ok!
  jhey: [missed]

  astearns: So little over time
  TabAtkins: I'd like to request resolution
  TabAtkins: last time was to have a UD, haven't done that yet
  TabAtkins: but it seems like to become an ED at this point
  TabAtkins: so would like to request an ED of this draft
  astearns: Any objections?
  [discussion of editors]

  RESOLVED: ED of Anchor Positioning, editors TabAtkins, iank, jhey

  astearns: Please make ED asap so we can file issueS!
  iank: I'm free to chat during break

<br duration=25min>
Received on Tuesday, 25 October 2022 23:00:27 UTC

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