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

[CSSWG] Virtual F2F 2021-02-11 Part III: CSS Conditional and Contain, CSS Ruby [css-conditional] [css-contain] [css-ruby]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Feb 2021 19:30:04 -0500
Message-ID: <CADhPm3sf8FUs8Zu1c5Sax45rOBatcbLq55W+PK0XRkM+Ka3gOA@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 Conditional and Contain

  - RESOLVED: Add new units to express container dimensions to
              container queries proposal (Issue #5888: "container
              width" and "container height" units)
  - Being able to handle responsive images in container queries (issue
      #5889: `srcset` and `sizes` interaction with container queries)
      has interesting use cases, but no obvious solution that
      addresses concerns around load time. There will be some
      experimentation with polyfills to try and see what works best.
      Additionally, Una and bkardell will reach out to the ricg for
      more feedback.

CSS Ruby

  - The group ran out of time before reaching a conclusion on issue
      #5927 (visibility:collapse on ruby annotations).


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

Scribe: dlibby

CSS Conditional and Contain

"container width" and "container height" units
  github: https://github.com/w3c/csswg-drafts/issues/5888

  una: This issue is regarding a new sizing unit
  una: One for container width and one for height, how inline vs.
       block is used
  una: Could be something useful for ui designed, similar to vw/vh
  una: Could be related to srcset based on container width, probably
       want different images based on container size
  <jensimmons> A big +1 from me for CW and CH. Or even just a unit in
               the inline direction if that's only what's possible.
               Such a thing will be very useful.
  una: Would like to get consensus on whether this concept
       (container-sized units) makes sense

  astearns: clarify - these units would key off of container size we
            discussed before?
  una: yes, could use for widths or similar to other viewport unit
  * leaverou notes that if these are doable, then the inline if() adds
             a "shorthand" syntax for container queries, e.g.
             flex-flow: if (100cw > 15em, row, column)

  florian: viewport units are useful, this sounds useful too. But
           perhaps we already have this via percentage?
  florian: If this is direct parent, then % gives you this - are there
           examples where this is not true?
  <bkardell> % doesn't work if it isn't your parent tho
  leaverou: font-size is one example
  florian: Realize there are cases where it doesn't work, but are
           those real use cases
  <iank> re: only your direct parent -> except in quirks mode :P

  emilio: This would resolve at computed value time?
  una: Yes
  emilio: The thing with srcset is that it might not quite work - how
          do they evaluate in media queries?
  emilio: Assume these would resolve against viewport size. don't want
          to wait until layout to start loading images, since it's a
          bit circular
  astearns: (this is the next issue)
  emilio: Sounds workable as long as we have a strong definition of
          what a container is

  astearns: Other comments/concerns?
  <leaverou> +1 for adding these units, if they are implementable
  <leaverou> perhaps cnw and cnh for names? (since ch is taken)
  <fantasai> leaverou what's the 'n'?
  <leaverou> fantasai: CoNtainer
  <fantasai> wfm
  <fremy> also +1 from me
  jensimmons: Big +1, when teaching viewport units people like them
              but not quite what they want
  jensimmons: Could really be useful for font-sizing
  jensimmons: Percent could work for margins, but this seems like
              something people will get excited for
  jensimmons: If we only get inline direction, maybe a minor
              limitation, but better than today
  astearns: Could see vw convert to this quickly
  <jensimmons> border thickness is another thing that cannot be done
               with %

  <leaverou> also is the container width unit essentially a container
             inline unit? Does it change with writing mode?
  <leaverou> (if so the unit could just be ci and cb)
  <fantasai> leaverou, I think we should pick a prefix that can allow
             expanded units in the future, so probably a 2-letter
             prefix [otherwise we'll head into conflicts with other
  <leaverou> fantasai: fair point

  astearns: See enthusiasm and support - resolve to pursue container
            units along with container queries?
  florian: We know we can have 2d containment, we suspect 1d, not sure
           on block - should this influence which units we want to
  astearns: Not quite sure followed previous discussion, though we
            were going to have a draft with 2d and everything, see
            what we can get
  florian: I think we can do 2d and inline, but not sure if we can do
  florian: or we won't do block yet, at least
  iank: Highly unlikely to be able to do block only
  iank: Would like to make sure we have use cases for block direction
  jensimmons: Border could be interesting. could set it 1/10th of
              inline, 1/10 of block on rectangular box

  fantasai: If we add block or things that may or may not exist need
            to define if they don't
  fantasai: Also should have a consistent prefix; 'c' and 'r' are
            problematic currently because of existing units
  fantasai: pick one we're unlikely to use or use a two letter combo
  una: rch sound good
  <fantasai> r is particularly problematic since we're using it as a
             prefix for root
  fantasai: We have to be careful as existing letters at the beginning
            won't work
  una: Let's bikeshed in the issue

  jensimmons: Liked leaverou's thought of only allowing inline/block
              instead of height width
  una: I'd like to keep symmetry of vw/vh to this proposal
  una: but do like inline/block [maybe also useful for viewport]
  fantasai: viewport units have logical units already
  <fantasai> (vi and vb)
  astearns: Let's bikeshed in the issue, get examples of what the CSS
            really looks like
  <una> Also should consider 4 names for height/width and inline/block

  astearns: Any objections to adding units, name tbd
  <dholbert> it's also worth thinking / defining what happens when the
             item & the container have orthogonal writing modes

  RESOLVED: Add new units to express container dimensions

`srcset` and `sizes` interaction with container queries
  github: https://github.com/w3c/csswg-drafts/issues/5889

  una: Next issue is related - how to deal with responsive images in
       container queries
  una: Would like to explore the solution space, since it seems like
       it'll be pretty common
  una: Adding a new syntax to srcset, setting images on each compute,
       since they come from server
  una: How should container queries interact, and background images
       are also a consideration
  una: Do something similar to media queries but seems important to
       consider for container queries

  bkardell: preloading - see linked article. You can't know what to
            load until later
  una: Yes, tricky because working at compute time, not sure how this
       works for viewport size
  emilio: You can estimate what your viewport is
  emilio: You can make a decent guess in iframes
  emilio: You can't really do this in containers
  iank: Relatively sure that gecko and chromium reference image via
        background: url(foo), but can have multiple declarations
  iank: UA load images after computed value time so you don't load
        lots of things in the background
  iank: It's a performance tradeoff
  emilio: <img> tags are a little more important as user wants to
          immediately see it
  florian: Worried that this could make slow connections slower
  florian: You normally don't get all resources at the first request,
           progressive modification, which happens more on slow
           networks. As this happens container can change, possible to
           congest/thrash network
  florian: That sounds unfortunate side effect
  una: If you're using container queries and there's a hero, or in a
       card, or sidebar, those are different
  una: If container queries allow for composable styles in components,
       I can't imagine that we can't have different image sizes based
       on the size
  <bkardell> not just image sizes maybe different art direction too?
  una: Not sure if it is slower to load a bunch of images first, or
       layout first then download other images

  florian: Use case makes sense - should and can are different
  florian: If you have multiple small parts, many changes could be
           happening, and as the stylesheet comes in over network, you
           might end up loading all the images
  florian: Ending up there sounds bad, but perhaps there's another
  myles: Problem appears endemic to container queries
  florian: Most thrashing doesn't hit the network for each change

  una: Perhaps we can scope to initial load to avoid this problem -
       maybe solves the majority use cases
  emilio: Not sure - if you resize the window, you'd be stuck in
          possible suboptimal state.
  myles: I don't think visual layout should be permanently affected
         based on network speed
  myles: CSS shouldn't be sensitive to timing of bytes on the wire
  una: Might be misunderstanding. when we figure out the layout size
       keep that image
  una: Refresh page would get different images
  emilio: layout while stylesheets are outstanding is common.
          stylesheet in body can affect the page layout, this should
          be taken into account
  iank: The place where this functionality may make sense is html
        layout. some components are already stateful, but this should
        be carefully considered e.g. a oneshot load - how does this
        affect the html layout, something to consider
  myles: Maybe specify behavior, UAs can use different heuristics
  myles: CSSWG doesn't have to specify when loads are triggered
  <nicole> a balance btw not requesting unnecessary images and not
           waiting to load images until css is done parsing
  iank: Option for this would be adding to Image specification (
        perhaps additional data on <img>) once this has been laid out
        and it reaches 'stable' state, then UA can fire off request

  nicole: Problem with container queries in general?
  emilio: Perhaps one approach is to define what the behavior should
          be (lazy or something). just a general problem with
          container queries.
  iank: Reasonably easy to polyfill, prototype, iterate to discover
        'good behavior'
  iank: Don't have to nail down spec text right now, we can try to
        find optimal via prototyping
  bkardell: Might be good to ask folks on ??? CG
  <jensimmons> yes, do ask Mat.
  bkardell: To the point of wanting different size, you might want
            different art directives(?)

  astearns: Is it possible to load different images?
  iank: Yes this is possible to get different urls
  astearns: That is for separate declarations, but this is for a
            single declaration
  iank: I was referring to img tag attribute, there's nothing in CSS
        currently that allows for this
  nicole: Having it in CSS should be the same problem as having this
          specified in the html itself. likely has same characteristics
  una: I recognize that this is probably for specification in HTML
  una: Glad bkardell brought up different images - third party service
       could provide different crops
  bkardell: Precisely, that's what I wanted to be recognized

  astearns: What else would you like to get from the group?
  una: This conversation basically
  astearns: Perhaps prototyping per iank is the way forward, thanks
            for bringing it up
  fantasai: And make sure it works on slow connections

  <bkardell> una it would be fun to call a meeting of all of the ricg
             people who might be interested in discussing... I'd be
             happy to help set something up if that's interesting
  <una> bkardell, yeah that sounds good!

CSS Ruby

visibility:collapse on ruby annotations
  github: https://github.com/w3c/csswg-drafts/issues/5927

  florian: Ruby has a number of uses, but primary use is Japanese/
           Chinese annotation of ideographs for pronunciation
  florian: Different preferences based on how experienced you are with
           the language, and what reading disabilities you might have
  florian: Printed you get what you get - in school you get most
           annotations, other materials not
  florian: but on digital media, we can easily have one source with
           multiple presentations. For ruby, can we hide bits that
           you don't want to see?

  florian: display:none doesn't work because it breaks pairing
  florian: visibility:hidden doesn't work because the annotation still
           takes up space in the layout
  florian: display:none fails because removes the box, box pairing is
           necessary. visibility:hidden doesn't break pairing, but
           still takes up space -- can cause base text to expand for
           such invisible annotations
  florian: However, visibility:collapse is another existing keyword,
           and is a natural use here
  florian: Define to hide the annotation, but keeps a box and preserves

  myles: Two examples - people that don't want pronunciation and those
         who are dyslexic and may get confused, wouldn't author hide
  florian: Maybe, maybe not. children-targeted annotations may only
           hide the 'easy' ones
  florian: or perhaps you're practicing and you don't want the help
           for certain characters
  myles: Could this be a browser feature instead of individual
  fantasai: But authors do need the ability to customize this.

  fantasai: Also allows "auto-hiding" on things that are not perfect
            matches for the text
  fantasai: Currently need an exact string comparison to do
            auto-hiding, but having some way to accomplish auto-hiding
            manually seems like a good thing

  myles: Use case is perhaps a bit narrow - this is yet another 'make
         it invisible'
  florian: It's an existing mechanism
  myles: But you're creating something new for ruby
  florian: visibility:hidden almost does what you want, but the box
           consumes space, you could make it small via font-size: 1px
           !important but is not great
  dholbert: What about contain:size with visibility:hidden?
  dholbert: Does that cover all the use cases?
  florian: contain:size does not apply to ruby boxes, if we're going
           to make new things apply, visibility:collapse makes more
           sense and is probably more scoped

  astearns: Is anyone using these hacks? do we know what things are
  astearns: If no one is performing hacks today to solve this, do we
            need support in browsers
  florian: There have been requests from DAISY organizations in Japan
  florian: They want to write all possible ways to display and have
           the user/author choose, but current implementations of ruby
           make it such that it is unreliable
  fantasai: We did get requests from a11y orgs in Japan, didn't make
            it up
  astears: Curious if existence of hacks can estimate how much people
           are running into this?
  [only Firefox has proper support for CSS ruby, so not much existing
  content atm]

  iank: Does visibility:collapse influence the container size?
  iank: My mental model is that it affects the container, but removes
        itself at the last minute
  iank: Doesn't seem to be the case here
  iank: That's what happens with table and flex, I believe
  fantasai: Flex affects one dimension but not the other
  fantasai: We could specify it similarly for ruby
  fantasai: It's a layout model specific thing - collapse the thing to
            see the layout without it, but don't remove the box from
            the tree, but have ability to re-show in a dynamic way
            without disturbing
  fantasai: This means different things in different models
  fantasai: In flexbox affects space in one, but not the other.
  fantasai: ruby proposal is to treat the same as auto-hidden ruby
  florian: Riffing on 'yet another way to hide' - it already hides,
           the way in which proposed hiding is already a thing in ruby
  florian: just marrying an existing property/value to existing
           behavior - don't need to invent anything new

  astearns: We're over time, perhaps can bring up again in the future
Received on Thursday, 25 February 2021 00:30:45 UTC

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