- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Feb 2021 19:30:04 -0500
- 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).
===== FULL MINUTES BELOW ======
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
usage
* 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
units]
<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
expose?
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
block
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
questions
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
approach
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
pairing
myles: Two examples - people that don't want pronunciation and those
who are dyslexic and may get confused, wouldn't author hide
all?
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
webpages?
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
easier/harder?
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